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INTERFACE FOR SATPS SYSTEMS 



Background Of The Invention 
[0001] 1. Field of the Invention 

[0002] This invention relates generally to the field of wireless communications. In 
particular, the invention relates to a method and apparatus for interfecing Satellite 
Positioning Systems ("SATPS") devices to different platforms independent of aides or 
protocols emanating from the platforms 



[0003] 2. Related Art 

[0004] The worldwide utilization of wireless devices such as two-way radios, 
portable televisions, Personal Digital Assistants ("PDAs") ceUular telephones (also 
known a "mobile phones"), satellite radio receivers and Satellite Positioning Systems 
("SATPS") such as Global Positioning Systems C'GPS"), also known as NAVSTAR, is 
growing at a rapid pace. As the number of people employing wireless devices increases, 
ti»e number of features offered by wireless service providers also increases, as does the 
integration of these wireless devices in other products. 

[0005] As an example, the present trend in the automobile and truck industry is to 
produce automobiles and trucks that have ampUtude modulation C'AM"), frequency 
modulation ("FM"), phase modulated ("PM"), short-wave C'SW") and single-side band 
("SSB") radios, mobile phones, GPS receivers, digital radios (also known as digital audio 
broadcasting "DAB" ^sterns) and satellite radios (also known as distal satellite radios. 
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or "DSRs," that receive progFamming from service providers such as, for example. Sinus 
Satellite Radio, XM SatelUte Radio, Orbit Satellite Television and Radio Network, and 
WorldSpace Corp.) The recreational ship, boat and airplane industries are also following 
the same trend as the automobUe and truck industry. Additionally, integration in wireless 
devices is occurring with the mobUe phone industry integrating GPS capabilities within 
the mobile phones to meet the Enhanced 91 1 (also known as "E91 1") services mandated 
by the United States Con^ss. 

[0006] As these wireless devices are integrated into products such as automobiles, 
ships, boats, airplanes, motorcycles, other transportation products and mobile phones, the 
cost and complexity of producing these products also increases along with the space 
requirements with a vehicle. Therefore, a goal of these industries includes producing 
these products with integrated wireless devices that have the highest performance at the 
lowest implementation cost. 

10007] As in many other areas of electronics, in order to minimize the 
implementation cost, retain a desired performance, and reduce component size, designers 
usually attempt to maximize the level of integration, minimize the complexity and 
minimize any adjustments that may be required (such as tuning). Unfortunately, the 
radio frequency "RF," intermediate frequency "IF," and baseband portions of a wireless 
device are usually the most difficult to implement with high levels of integration, reduced 
complexity and minimal, or no, tuning. Additionally, in order to allow the radio sections 
of a mobile telephone handset to communicate with the GPS receiver section of the 
handset an interface is need that allows for signal mformation to be properly 
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communication between the GPS receiver and the radio sections. This is additionally 
true if tiie GPS receiver and/or radio sections desire aiding between the different sections. 

Detailed Description Of The Preferred Embodiments 
[0008] A typical Satellite Positioning Systems ("SATPS") such as Global Positioning 
System ("GPS") system has approximately 12 satellites that may be visible at any one 
time to a wireless device. Global Positioning System or "GPS" means any system 
utiUzing satellites and/or land-based communications devices for providing or enabling 
the determination of a location of the wireless device on the earth, for example but not 
limited to: NAVSTAR, GLONASS, LORAN, Shoran, Decca, or TACAN. 
[0009] GPS is an example of a satellite based navigation system that may be utilized 
by GPS portion of the combined GPS and radio system ("CGRS") to pinpoint its location 
on earth. The array of GPS satellites transmits highly accurate, time coded information 
that permits CGRS to calculate its exact location in terms of latitude and longitude on 
earth as well as the altitude above sea level. The GPS system is designed to provide a 
base navigation system with accuracy to within 100 meters for non-military use and 
greater precision for the military. 

[00010] The space segment of the GPS system is a constellation of satellites orbiting 
above the earth that contain transmitters, which send highly accurate timing information 
to GPS receivers on earth. The fully implemented GPS system consists of 21 main 
operational satellites plus three active spare satellites. These satellites are arranged in six 
orbits, each orbit containing three or four satellites. The orbital planes form a 55° angle 
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with the equator. The satellites orbit at a height of 10,898 nautical miles (20^00 
kilometers) above earth with orbital periods for each satellite of approximately 12 hours. 
[00011] Each of the orbiting satellites contains four highly accurate atomic clocks. 
These provide precision timing pulses utilized to generate a unique binary code (also 
known as a pseudo random or pseudo noise "PN" code) that is transmitted to earth. The 
FN code identifies the specific satellite in the constellation. The satellite also transmits a 
set of digitally coded ephemeris data that completely defines the precise orbit of the 
satellite. The ephemeris data indicates where the satellite is at any given time, and its 
location may be specified in terms of the satellite ground track in precise latitude and 
longitude measurements. The mformation in the ephemeris data is coded and transmitted 
from the satellite providing an accurate indication of the exact position of the satellite 
above the earth at any given time. A ground control station updates the ephemeris data of 
the satellite once per day to ensure accuracy. 

[00012] A typical GPS receiver configuration is designed to pick up signals firom 
three, four, or more satellites simultaneously. The GPS receiver decodes the information 
and, using the time and ephemeris data, calculates the approximate position of the GPS 
receiver. The GPS receiver contains a processor that performs the necessary calculations 
and may output a decimal display of latitude and longitude as well as altitude on the 
handset. Readings firom three satellites are necessary for latitude and longitude 
information. A fourth satellite reading is required in order to compute altitude. 
[00013] The invention encapsulates all the geolocation protocol implementation in the 
Call Processing, ("CP") and communicates SATPS, more specifically, Global Positioning 
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System ("GPS") assistance informatioii to and position or other geolocation results 
(example: pseudoranges, code phase etc.) from the client, also known 'as the ("SLC"), 
through a geolocation protocol independent interface. 

[00014] The '•face-value" advantages of the present invention, enables the GPS portion 



using the present invention, can be implemented as a translator from the platform 
protocol to the independent protocol used by the GPS chip, thereby allowing seamless 
availability of geolocation information as the mobile handsoff from one wireless 
communication standard to another, thereby changing the way in which it receives 
assistance data and transmits position or other geolocation results from the Call Processor 
(phone) to a remote aiding server. Each imique geolocation protocol (IS-817, IS-801 
etc.) for all different air interfaces used in various places around the world can now be 
served by a single GPS implementation without resetting or reconfiguring the GPS 
subsystem, where the present invention is used to translate the GPS information to the 
protocol used by the conrununication system subscribed by each customer, and vice versa. 



of the system to be free of implementation of multiple protocols. Each protocol, when 
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[000151 ^ ^ 

[00016] Figure 1 - Wireless Mobile Position System Architecture - AI3 Architecture 

[000171 Geolocation protocols are Application Protocols 

[00018] Contrary to many protocol stack levels, Geolocation protocols are application 
protocols, which means they deal with the semantics (meaning) of the message, not by 
merely transporting data from one side to the other side, without error and eliminating 
swapping or repetition as in a TCP-IP stack. 

[00019] Therefore, the entity which handles the protocol (e.g., decides to request some 
data) needs to know what those data will be used for, and the meaning of every parameter 
exchanged over the protocol (needs to know the GPS side). Any attempt to separate the 
decision to request information from the actual creation of the message which requests 
the information will most likely be inadequate. As such, the impleraenter of the 
Geolocation protocol has to be GPS "savvy" to do a correct job. 
[00020] Current Implementation 
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[00021] In the present current implementation, the strategy is intimately merged into 
the air-interface Finite State Machine ("FSM"). This means that the state in which the 



memory, and that the decision to send a request message to complete some incomplete 
GPS information is built-in in the FSM itself. There is currently no way to separate the 
strategy from the protocol handling. 

[00022] Handset Design Concept with AI3 for GSM/3GPPThe purpose of the AD 
concept is to make the SLC based handset to work with any geolocation air-interface 
protocol for network aided data with or without SiRFLoc Server. The current AI3 
architecture supports the network aiding with Ephemeris data or Almanac data. 
[00023] Figure 2 shows the high level architecture of AI3 to be implemented mside the 
RRLP based handset. The CP shall conununicate with the SLC via a RS232 link and 
, hardware lines (for the time and frequency transfers) as described in Figure 2. The F and 
G are two separate logical chaimels for the RS232 interface. The G interface is designed 
to pass the AI3 aiding data to SLC. The rest of the aiding data will be passed to SLC via 
the F interface. On the SLC side, the F interface is a standard SiRFLoc client interface 
and the G interface is transparent to any standard air-interface protocols. The CP shall 
generate the AI3 data via an "RRLP message to A13" converter. The AI3 data will be 
packed into the G mess^e format via an AI3 interface message handler before passing to 
SLC via the RS232 link. The CP may obtain the time, and reference location data from 
an appropriate RRLP air-interface messages and pass them to SLC via appropriate "F' 
interface messages. 



FSM is currently is imposed by the current knowledge of the contents of the GPS 




[00025] Figure 2 - General concept of AI3 architecture for RRLP/GSM based handset. 
[00026] How to split strategy from protocol handling 

[00027] The present invention implements, at design time, per piece of assistance 
information an "information dependency tree" which would work on the "barebones" or 
"GPS core" native GPS aiding interface. 

[00028] There is a dependency tree per type of assistance information necessary for 

the GPS core. As an example, we might have a tree description per each piece of 

following assistance information, necessary to preset the search: 

[00029] Doppler, Doppler uncertainty, Code offset, Code offset uncertainty. 

[00030] The leaves of each tree are elementary GPS information, which can be already 

available at the SLC (i.e. found in the non-volatile intemal memory), or can be retrieved 

through the geolocation protocol. 
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[00031] The stems of the leaves are a mathematical expression which converts a set of 



elementary information into a single information of lower level (example: ephemeris of 
satellite PRN #5, pl\is current GPS time allows to compute satellite position at the given 
time) 

[00032] The strategy algorithm identifies what are the "information leaves" with 
available information (from memory), identifies several ways to get to the root of the tree 
(fipal desired information), and for every possible way to go to the root, identifies: 
[00033] How many pieces of information are missing and necessary to go to the root, 
[00034] How much computation steps it necessitates to go to the root information. 
[00035] How much cost (time, air-interface bandwidth) is associated with the retrieval 
of this piece of information through the protocol. 

[00036] The least costly method is chosen and attempted. If failed, the second less 
costly is attempted, etc, until the information is retrieved for the system. 
[00037] The cost function associated with the dependency trees is very dependent on 
the geolocation protocol. 

[00038] The next step is to "map" those identified GPS elementary parameters into 
one or several different message requests (there is a chance that all parameters will not be 
returned in the same message), and finally to trigger the proper request messages. 
[00039] Some GPS elementary parameters might not be avsdlable through the given 
interface, and the cost function can then be assigned to infinity, to prevent the algorithm 
from trying to obtain such information. 
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[00040] In the returned message, the received parameters have 'to be extracted, 
identified with the GPS elementary parameters, refonnated into the format expected by 
the barebones interface. In some cases, some mathematical transformation will have to be 
applied by the customer, e.g., approximate position given in ECEF and requested in 
Lat/Lon/Alt by the generic interfece. 

[00041] The independence of the generic interface with the messages and formats of 
the Geolocation protocol is obtained at the expense of: that the geolocation protocol 
implementer needs to have a significant expertise about GPS technology(to map 
Geolocation messages into generic parameters), and needs to know very well how the 
strategy algorithms work (to define the cost functions). There is still a protocol 
(interactive) to develop to let the CP know what are the required parameters, and how to 
return the results to the SLC. The best way to eliminate this protocol is to implement this 
idea only in a single processor, handling both CP and SLC functionnalities. The protocol 
is thus reduced to function inter&cing. 



[00042] Possible Approaches to the Air Interface Independent Interface 

[00043] If the customer wishes to implement the geolocation protocol within the CP 

system, the customer must implement all of the parts of the protocol that are currently 

implemented today in the SLC as a single Finite State Machine: 

[00044] -Message coding/decoding, 

[00045] -Protocol management (sends/receives messages, manages timeouts/retries...), 
and 
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[00046J -Strategy (what messages to request to the server, how to report the results to 
the GPS receiver), 

[00047] The coding/decoding and protocol management are usually well defined in the 
geolocation standard protocol documents, and would be no problem to the user. 
[000481 The real issue is the strategy implementation, which is highly dependent on 
what the customer knows about the GPS processing section and the GPS environment. 
Typically, only the SLC has the context in which the GPS assistance is requested, e.g., 
knows what the stored ephemeris, last computed position, RTC time, etc. are, and thus is^ 
typically the only device that can implement the strategy part There are several 
approaches to alleviate that serious problem: 

[00049] 1)- The interaction between SLC and CP is eliminated by using an interface 
instead of a protocol. Such a system typically is a very inefficient interface, and has 
limited performance. 

[00050] 2)- The interaction between SLC engine and CP is elimmated by "canning" 
the requests. This must been agreed at design time between the CP manufacturer and the 
GPS manufacturer. The customer protocol module will systematically send the same 
subset of requests picked from the geolocation protocol. Once the protocol interactivity 
is broken, this solution has exactly the same performance problems as solution 1). 
[00051] 3)- The strategy is implemented in the SLC and the CP just sends the requests 
decided in the SLC. 

[00052] Here are the possible ways to make this connection between protocol and 
strategy (on two physically separate processors, which are connected by a serial link) 
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[00053] a)-create a "meta-protocol" for every request possible in the geolocation 
protocol, cieate a corresponding message in the meta-protocol. Completely lose the air- 
interface independency, as the "meta-protocor mimics every message in the initial 
geolocation protocol. Create another layer of protocol which does not add any 
advantage, and increases the complexity of the implementation. It is much simpler to 
send and receive the geolocation messages themselves. 

[00054] b)-create a protocol based on "generic" GPS assistance interface every bit and 
piece of information the GPS receiver might need is catalogued in a generic Ust, like 
"ephemeris parameters of the satellite PRN #5", "ionospheric mforraation." The list can 
be very long and redundant, as there are quite a few ways to split this information. The 
format conversion from geolocation protocol into generic assistance information must be 
done by the customer, who will need some level of GPS expertise. Some GPS-specific 
mathematical transformations could also be required to be implemented by the customer, 
which makes the generic interface less desirable. 

[00055] To answer the request of having the customer in charge of the geolocation 
protocol the present invention envisions at least three technically viable solutions: 
[00056] 1) Implement a generic interface, without interaction, using a very limited 
number of parameters. Such an approach is easily unplemented, but suffers from lack of 
extension at later phases or upgrades to the system. 

[00057] 2) Have the customer implement their own code inside the SLC, as in the 
SDK, according to the current GPS receiver architecture. 
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[00058] 3) Have the customer implement their own code inside the SLC, but using 
"generic assistance" with the bare-bones GPS core, but inside the SLC. To develop the 
generic interface, we need to implement at least one geolocation protocol completely in 
the SLC (preferably a complicated one), as it is the only way to leam the best way to do 
"generic assistance" with GPS core interface. 

[00059] In the case where the customers want to be the "owners" of the geolocation 
protocol inside the CP, this AD could be used between the CP and the SLC. 
[00060] It should be usable over a large range of geolocation standards, as it is a 
reduction to the "most common denominator" of all of them. As it is tiie most common 
denominator of quite a few standards, it will typically not be optimized for any of them. 
It also typically allows only one single form of assistance, e.g., ephemeris. This interface 
is designed to be used between CP and SLC over a serial connection local to the mobile 
device. It will be difficult to use such an interface over the airwaves, air as the volume of 
exchanged information is quite significant. 

[00061] AI3 can also be used as a "quick" and sub optimal way to implementation on 
' a large variety of air interfaces and a large range of customers, and can be used to allow 
the SLC to roam to different networks that have different protocols. For example, the 
present invention can be used as the "standbd roaming" geolocation interface (when the 
phone is not in is home network), aside from the "main" geolocation protocol. 
[00062] Configurations and requests 
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[00063] The decision to use the AI3 (or another choice) is made by the CP and notified 
to the SLC by a special "air-interface" code in the session opening message of the "F" 
interfoce. 

[00064] Fm plicit assistance 

[000651 All implicit assistance (Tune transfer, Frequency transfer) is transmitted over 

tiie "F" interface as in the past 

[00066] MS approximate position 

[000671 If aviulable, transmitted over the "F" interface. 

[00068] MS Position report 

[00069] The position is returned over the "F" interface 
[00070] Nmnber of r equested positions 

[00071] In the majority of the geolocation interfaces, this is specified in one of the 
over the air messages. Here, the assumption is that the position is periodically and 
continuously required until the session is closed (to confirm). The only information 
exchanged over the "AI3" is the GPS assistance information by a mechanism called the 
memory mirroring concept 
[00072] "Memory m irroring" concept 

[00073] The interface is defined as a large data structure, which will be probably 
implemented as a memory section. All information present in the interface has a 
predetermined position in tiiis large structure. To signify the vaUdity of every piece of 
information, a validity flag is also assigned to every field in this structure. 
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[00074] The transmission of the information is simply a "read and transmission byte 
by byte" of the foil structure in a predetermined order (MSB first, etc.). The Client side 
has a similar data structure, and is filled out byte by byte as soon the information comes. 
A single checksum test is made on the full structure for validating it. 
[00075] Reduction of "memory mirroring'' message size 

[00076] In some cases, not all ephemeris will be vaUd, and in theory, the message 
could be shortened by sending only the ephemeris slots actually having valid mformation. 
This should be avoided as the memory mirroring mechanism should not be dependent on 
the meaning of the message. 

[00077] A way to accomplish that is to choose the convention of putting all unused 
fields (including the validity fields) to "0". A simple compression mechanism, sending 
the number of consecutive bits set to zero, instead of the bits themselves, could be used 
for the same purpose. 

* [00078] This mechanism requires the use of a unambiguous special metacharacter, 
preceding a fixed field indicating a number of repetitions of consecutive bits set to "0" 
instead of the bits themselves. 
[00079] Contents of memorv mirroring structure 

[00080] This is strictly composed of ephemeris information, and possibly ionospheric 
parameters, excluding any other type of assistance. Note that some assistance received 
over the air interface protocol can be delivered to the SLC through the "F' interfece 
(approximate user location for example). 

[00081] Duration of transmission of the memorv mir roring message 
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[00082] The si25e of ionospheric mode is 64 bits, ephemeris data per satellite is 407 



bits, num_sv is 8 bits, iono^flag is 1 bit; for 8 satellites the size is 8+1+64+407*8=3329 
bits; for 10 satellites is 4143 bits. At 9600 baud, the message is transmitted in less than 
0.5 second, which will not impact the TTFF. 

[00083] Message Timing, Timeout: Within a few seconds after the Session Opening 
Notification Message has been returned to the CP, the CP should start to send this 
structure byte by byte in the predetermined order. If the information is not available at the 
CP, the structure should be send anyway, with all validity flags to "non valid*'. 
[00084] If the SLC has not received a single character within few seconds (2?) after it 
returned the Session Opening Notification Message, it will send some type of very simple 
"NACK" message over the "D" interface, requesting the CP to send the information 
again. The 'T^ACK" message will be reiterated every (2) seconds until a complete 
message is received and declared usable, or a Session Closing Request Message is 
received. At any tune, when the information or part of it has been updated in the CP 
structure, the message can be resent at will by the CP. As it is another "D" interfece, no 
AD message can be sent before a Session Opening Request/Response pair, or after a 
Session Closing Request/Response pair. 
[00085] Transport mechanism: 

[00086] This is a transport interface ahready adopted in SLC, including header, 
payload checksum trailer. A "memory mirroring type" is added in front as an equiv&lent 
to "message type", to allow extension of this interface in the fixture. 
[00087] Checksum 
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[00088] Checksum in the transport inedianism is only for checking the integrity of the 

structure, not to correct errors. The trivial error mechanism we want to protect from is 

one missing character. 

[00089] The interlace of the present mvention can be used as a defeult air interface, 
which may have some limitations but is always available to the CP. Further, the interfece 
can co-exist with other interfaces as a backup interface shovdd the other interface fail. 
The Aiding Independent InteroperabiUty Literface (AI3) Interface Control Document is 
attached as Appendix A. 

[00090] The adoption of the interface of the present invention will facilitate the 
integmtion of CP and SLC functions on a single processor. In such an environment, the 
assistance data exchange between CP task and SLC task will be very probably made over 
a shared memory. The memory structures currently in tiie CP and SLC sides would be 
merged in a smgle structure; the "memory mirroring" mechanism would be simply 
eliminated, but the writmg and reading fimctions to this shared memory would stay the 
same. 

[00091] The foregoing description of the preferred embodiment of the invention has been 
presented for the purposes of illustration and description. It is not intended to be exhaustive 
or to limit the invention to the precise fonn disclosed. Many modifications and variations 
are possible in hght of the above teaching. It is intended that the scope of the invention not 
be limited by this detailed description. 
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Overview 

This document defines procedures and messages related to the **Aiding 
Independent Interoperabilily Interface" (AI3) between the Call Processor 
(CP) and the SiRFLoc Client (SLC). The procedures and messages defined 
in this document are designed to be used in addition to SiRFLoc Client 
Interfajce Control Document ( Ref 2) to support wireless aided mobile 
positioning services using the SLC. 

The following goals were used in developing this document: 

• Comply with the existing aiding transport mechanism in Ref 2, hence 
minimizing the required modifications to Ref 2 to support the AI3; 

• AI3 is usable and unique for a large range of geolocation standards. 

• The Air-Interface Protocol Stack is implemented by the customer in 
the Call Processor, 

Glossary 

2D Position. A two-dimensional (latitude and longitude) position. 

3D Position. A three-dimensional (latitude, longitude, and height) 
position. 

Aiding Data. The aiding data provided , by the base station to the mobile 
station for various purposes (e.g., acqviisition, location calculation or 
sensitivity improvement). 

Generic Geolocation Server Station. This term refers to the entity in 
the network which provides aiding (GPS-related or other) information to 
the SLC, and retrieves the position results. It has different names 
depending on the cellular platform of interest (PDE for IS801, GMLC for 
GSM,...) 

Call Processor (CP). The dedicated hardware and software to establish 
and manage a wireless radio connection. 
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Ephemeris. The ephemeris data are embedded in tJie GPS Navigation 
Message. The precise (high accLiracy) orbital parameters of one GPS 
satellite, as transmitted by that satellite in the GPS Navigation Message 
Subframe 1, 2, and 3, The ephemeris also includes satellite clock 
correction. 

Geolocation. The process of determining a geographic location. 
GPS. Global Positioning System. 



LSB. Least Significant Bit 

Mobile Station (MS), It consists of a CP and a SLC, communicates with 
the base station and receives GPS signals. 

MSB. Most Significant Bit 

SiRFLoc Client (SLC). The SiRFLoc GPS section embedded in the mobile 
station. It is composed of a protocol layer, to dialog with the CP and SLS 
through the CP, on top of the SiRF GPS core technology (hardware and 
software). ' 

SV. Space Vehicle or Satellite. 
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AI3 Functional Architbcturb 

For purposes of this document, the mobile station (MS) consists of a CP 
and a SLC. The CP refers to the dedicated hardware and software to 
establish and manage wireless communication with the base station. The 
SLC refers to the GPS section to receive GPS signals and determine the 
mobile station geographic location. The SLC can be as a subsystem or 
integrated as IP. It is composed of the "Aiding Independent 
Interoperability Interface" layer, to dialog with the CP, on top of the SiRF 
GPS core technology. 



Whereas SiRFLoc encompasses several architectures, one of the 
architectures in which AI3 interface shall be used is the "Aiding 
Independent Interoperability Interface Functional Architecture". The CP 
implements a Geolocation air-interface protocol (from Geolocation Server to 
CP) and then pass GPS aiding information received from the base station 
to the SLC, over the AI3 as shown in Figure 3. 
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Figure 3-Wireless Mobile Positioning System Architecture-AI3 Architecture 



Table 1 describes the interfaces shown in Figure 3, There are different 
geolocation standards developed for different types of wireless networks; 
any of them can be the "H'' interface. 



• Table 1-Interface Description 



Interfa 
ce 


Functional 
Entities 


Protocol 


Description 


H 


Geolocation 
Server-CP 


Air-interface 


Various geolocation standards. 
Controlled by the CP 
manufacturer. 


F 


CP-SLC 


SiRFLoc 
Specific 


SiRFLoc Client Interface Control 
Document 


G 


CP-SLC 


SiRFLoc 
Specific 


AI3'Defined in this document 



The F interface, which is the client system interface between SLC and 
CP, is defined in Ref 2 document. It acts as a bootstrap protocol, ever 
present, allowing the CP to choose at run-time how the aiding will be 
conveyed to the SLC in the aiding encapsulation layer. The CP can 
choose between an air-interface "H''(case of the end-to-end system 
architecture) or the AI3 ("G"). It is designed to perform one or more of the 
following tasks: 
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• SLC hardware management from the CP (power on/ off, reset); 

• If available, implicit aiding interface, i.e. time and frequency transfer 
from network (or from CP real time clock) via the CP, and approximate 
MS position (implicit from the network, if it does exists); 

• Session opening/ closing (i.e. notifying the SLC that an air-interface 
connection has been opened/ closed); 

• In a dual-mode MS, notifying the SLC what air interface is on, and 
thus notifying the SLC what set of geolocation air-interface protocol to 
use to dialog with the SLS; 

In the "Aiding Independent Interoperability Interface Architecture", it is 
the CP developer's responsibility to implement the Geolocation protocol 
that is used between the Geolocation Server and CP. The "G'' interface is 
used to convey GPS Aiding information received from the base station to 
the SLC, There is no reason why ''G*' and "F" cannot be integrated into a 
sin^e protocol or interface, logical and/ or physical. 

This document defines the "G" interface. Since there are many existing 
Geolocation protocols, the "G^ interface is designed to be usable oyer a 
large range of Geolocation standards and air-interface independent, i.e. it 
is unique for applicable air-interfaces. The ''AIS" is actually a reduction of 
the applicable Geolocation standards. It will not be optimized for any of 
them. 

The CP sends position request information and network aiding 
information in AI3 format to SLC through the G interface. In return, the 
SLC sends position results or error notification to CP though the same 
interface. ' 

All Geolocation protocols, including SAMPS, GSM, and CDMA, work 
under the interaction paradigm. The base station sends back only what 
the mobile station has requested. The strategy to perform the interaction 
is highly dependent on the knowledge on the SLC processing. Oxdy the 
SLC can optimally implement the strategy part. 

Currently, the AI3 supports only one-way aiding. There is no reason why 
this cannot be two-way. The interaction between SLC and CP required for 
performing the interaction strategy, is eliminated by "canning" the 
requests. The "canned requests" are a subset of requests picked from the 
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Geolocation protocol at design time and will be systematically sent to the 
Geolocation Server. No control on the. interaction can be applied by the 
SLC. The CP passes the aiding data through AI3 without any request. The 
SLC cannot stop it or tailors it. Since the protocol interactivity is broken, 
the performance won't be optimal. 

In one embodiment, AI3 shall be used exclusively between CP and SLC 
over a serial connection in the mobile station. While it is recommended 
that AI3 not be used over the air as the volimie of exchanged information is 
quite significant and would adversely impact the Time-To-First-Fix (TTFF), 
once can use this interchange via a remote connection. 
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AI3 INTBRFACB 

Physical Interilace between CP And SLC 

As shown in Figure 4, the physical interface between the CP and the SLC 
consists of a RS-232C serial conununication link and two hardware lines 
inside the mobile station. 





RS 232C 








► 




CP 






SLC 




H/W Lines 





Figure 4-Fhysical Interface between CP and SLC 

The serial link is a bi-directional electrical (ex: TTL level) conununication 
interface and used to exchange messages between the CP and the SLC. 
In addition, there can be other hardware line/s utilized for other type of 
aiding, ex: time and frequency transfer. 
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Common Transport Mechanism 
Generic Packet Format 

The existing transport mechanism in Ref 2 is used to transport the AI3 
packets. The TYPE FIELD shall be "0x01", corresponding to either an "Air- 
Interface Message" or an "AIS message". 

To Switch to AI3 interface in Session Opening Request message, the CP 
shall notify the SLC that it shall send the aiding data in "AIS" by using the 
appropriate value in ''SESSION_OPEN_REQ_INFO'' format as described in 
Ref 2. 



It is to note that, aside from the "AIS", the CP and SLC can support other 
air-interfaces that can be activated at run-time using the appropriate 
value for the "SESSION.OPEN.REQJNFO" field. 

AI3 Packet Structure 

The AI3 segments defined here shaU be sent in the PAYLOAD field as 
shown in following table: 

Table 2-AI3 Packet Structure 



HEADER 


LENGTH 


UDGICAL 
CHANNEL 


PAYLOAD 


CHECKSUM 


TERMINATOR 








MSG_I 

D 


SEGMEN 
T 






2 

Bytes 


2 

Bytes 


1 Byte 


1 Byte 


M Bytes 


2 Bytes 


2 Bytes 



MSG_ID Message Identifier. 
SEGMENT Message Segment. 



AI3 Segment Format 
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An AI3 Segment includes three fields. The first byte presents the total 
number of segments used for transporting the AI3 message. The second 
byte is the segment index starting with 1. The last field is the compressed 
AI3 data with a maximum size of 1016 bytes. 



Table 3- A13 Segment Fonnat 



PAYLOAD 


MSG ID 


SEGMENT 




NUM_OF_SEGMENTS 


SEGMENTJNDEX 


COMPRESSED„AI3_DATA 


1 Byte- 


1 Byte 


1 Byte 


<= 1016 Bytes 



NUM_OF_SEGMENTS Number of segments 

The AI3 data may be sent in several segments. This field indicates the total number of 
segments for a complete set of AI3 data. 0 is an invalid number. 

SEGMENTJNPEX Segment Index 

The value of this field is the sequence number of the AI3 data segment transported by 
this message. Its range is from 1 to 255. The last message of the AI3 data set has 
SEGMENTJNDEX equal to NUM^OF^SEGMENTS; 0 is an invaUd number for this field. 

COMPRESSED AI3 DATA Compressed AI3 data 
This field is a section of the compressed AI3 data. 

Maximum Packet Size, Maximum Segment Size 

Each PAYLOAD field in a AI3 packet has a maximum total size of 1019 
Bytes, and therefore, only transports a maximum of 1018 bytes in the 
SEGMENT field . 

As every segment has a 2 bytes header, if the size of the compressed AI3 
data is larger than 1016 Bytes, it needs to be segmented; each segment 
shall be sent sequentially in a separate packet 



Message Compression Method 
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The size of some of the messages is quite large. At 9600 baud rate, it 
takes about 2.14 seconds to transmit the AI3 Data message with 8 
visible ephemeris and without Almanac data. 

Actually, not all Data in a message will be valid, which means there are a 
lot of fields set to 0. A simple data compression algorithm will significantly 
reduce the size of the data to be transmitted. The data compression 
algorithm shall be a lossless type of compression and manipulate byte 
streams without regard to what the bytes mean. It shoxold also be easily 
implemented and quickly executed. 

The data compression algorithm applied to all AI3 messages is a 
"packbits'' method, which is a very simple and popular variant of run- 
length encoding method. A run is a group of identical consecutive 
characters. Each run is coded as a 2-b5rte header that describes what 
kind of run it is and its length, and one or more bytes that contains the 
data. In all cases, the header is split into two sections: its MSB describes 
whether it is a literal run (uncompressed) or a fill run (compressed), and 
the next 15 bits specify the length of the run, as shown below. 



Table 4-RLL Compression-Header Format 



15 


1 
4 


1 
3 


1 
2 


1 
1 


1 
0 


9 


8 


7 


6 


5 


4 


3 


2 


1 


0 


RUN_INDICATOR_BIT 

0 = uncompressed 

1 = compressed 


LENGTH (bytes) 



A literal run is a run of literal bytes (i.e. bytes which are stored rather 
than compressed). In this case, the RUN_INDICATOR_BIT is 0 and the 
lower 15 bits specify the length of the run of the literal bytes. The literal 
bytes are then encoded directly after this header. 

A fill run is a sequence of bj^es where all the bytes are identical. In this 
case, the RUN_INDICATOR_BIT is 1 and the lower 15 bits specify the 
length of the run. The header is followed by the byte which shotdd be 
copied the given number of times. One example is given as follows to 
show how the data compression algorithm works. 
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Origin byte stream: 0x01 OxFF 0x00 0x89 0x00 0x00 0x00 0x00 

0x00 0x00 0x00 0x12 
After compression: 0x00 0x04 0x01 OxFF 0x00 0x89 0x80 0x07 
0x00 0x12 

The data decompression algorithm is also very simple. The SLC shall get 
the RUNJNDICATOR^BIT and the length. If the RUNJNDICATOR^BIT is 

0, the next LENGTH bytes are just copied. If the RUNJNDICATOR_.BIT is 

1, the next coming byte shall be copied "LENGTH"' number of times. For 
example: 

Compressed data: 0x80 0x08 0x00 0x00 0x05 0x44 0x00 0x01 

0x66 0x45 

After decompression: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x44 0x00 0x01 0x66 0x45 

Special rules for compression/ decompression implementation 

No matter their size, all transmitted messages shall be co mpressed. 

To simplify the implementation, on transmission side, the message 
preparation shall be done in the following sequence: 

-Message Coding 

-Compression 

-Segmentation 

Figure 5-Coding/ Compression/ Segmentation Sequence 
TRANSMISSION SIDE 



CODING 



V 



COMPRESSION 



SEGMENTATION 



Transnnjssion 



For compatibility, the message processing at the receiving side shall be 
done in ttie reverse order: 

-Segment validation and reassembly 

-Decompression 



31 



U.S. Express Mail No.: F.II088610790US 
Filing Date: August 14. 2002 



PATENT 

EG Matter No. CT02G01USV 
149-US-Pl 



-Decoding 

Figure 6-Reassembly/Decompression/Decoding Sequence 

RECEPTION SIDE 



Reception 



REASSEMBLY 



j\ 

1/ 



DECOMPRESSION 



j\ 
1/ 



DECODING 



Also for ease of implementation reasons, the compression applied at the 
transmission does not need to be optimal. The decompression on the 
receiving side must accommodate this non optimal compression method. 
The compression is non optimal because: 

-only a sequence of consecutive ''0x00'' can be coded in a compressed 
run. 

-all consecutive "zero** bytes do not need to be grouped in a single 
compressed run. 

-"zero** bytes can be coded in a non compressed mode as well. 

-a new header can be introduced anywhere in the sequence (for example 

to independently compress every logical section). 

-a *'run*' (or span between two consecutive RLL headers) can overlap two 
segments. 



-Even if the compression is not optimal, the compressed message size 
should not go over "size of original message plus 2 bytes'*. 

Exsunple of worst case of allowed compression (compressed size=original 
size plus two): 

Original message: 0x01 0x00 0x00 0x00 0x00 0x10 0x20 

0x30 0x40 0x50 

Compressed message : 0x00 OxOA 0x01 0x00 0x00 0x00 0x00 0x10 

0x20 0x30 0x40 0x50 
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Elxample of forbidden compression case (compressed size> original 
size+2): 

Original message: 0x00 0x01 0x00 0x01 

Compressed message: 0x00 0x01 0x00 0x80 0x01 0x01 0x00 0x01 

0x00 0x80 0x01 0x01 0x00 



AI3 MESSAGE Definitions 



Aside from the ACK/NACK message, All information present in the AI3 
data messages has a predetermined position in a large structure. To 
signify the validity of every piece of information, a validity flag is also 
assigned to each group of information in this structure. This special 
arrangement has been chosen to facilitate the conversion of this protocol 
as a shared memory between tasks on a same processor. For now, the 
AI3 protocol is specifically designed to be used over a serial link, between 
two separate processors. 



Detailed Message Definitions 

1 

Currently, Three AI3 messages, the AI3 Request, AI3 Response and the ACK/NACK 
message are defined. The following table gives their message identifiers. These messages 
can be increased if required. 



Table 5- AI3 Message ID 



Messages 


MSG ID 


CP SLC 


AI3 Request 


0x01 




AI3 Response 


0x02 


< — 


ACK/NACK Message 


0x03 


4 > ► 



AI3 Request 

An AI3 Request is amongst other elements composed of position request 
information, ionospheric parameters, satellite ephemeris and almanac. In 
addition, other aiding data received over the air interface protocol can be 
delivered to the SLC through the ^'F* interface (for example, approximate 
user location, time and frequency transfer). 
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To signify the validity of every piece of information, a validity flag is also 
assigned to each group of information in this structure. 

Some of the AI3 Request message represents information conveyed from 
the CP to the SLC and is. described in Table 6: 



Table 6- AI3 Request Message Before Compression 











POS_REQ_FLAG 


8 






NUM FIXES 


8 






TIME_BTW_FIXES 


8 


1 


Seconds 


HORI_ERROR_MA 
X 


8 

/ 




(See Table 7) 


V E/K, 1 _ Jl* JtvXvVj K_lVi/V 

X 


Q 
O 

1 




^oee 1 aoie f } 


RESP TIME MAX 


8 


1 


Seconds 


TIME_ACC_PRIOR 
ITY 


8 




(See Table 8) 


ALM_REQ_FLA.G 


8 


N/A 


N/A 


IONO_FLAG 


8 


N/A 


N/A (See Table 9] 


ALPHA_0 


8(1) 


2-30 


Seconds 


ALPHA_1 


8(1) 


2-27 


sec / semi-circles 


ALPHA_2 


8(1) 


2-24 


SQc/(semi - circles^ 


ALPHA_3 


8(1) 


2-24 


sec/(semi - circles^ 


BETA_0 


8(1) 


2" 


Seconds 


BETA_1 


8(1) 


2'* 


sec / semi-circles 


BETA_2 


8(1) 


2" 


sec/{semi — circles)^ 


BETA_3 


8(1) 


2^6 


SQcli^semi — circles)^ 



The structure shall include 32 occurrences of the following record of 
ephenieris parameters: 



EPH FLAG 


8 


N/A 


N/A 


SV_PRN_NUM 


8 


N/A 


N/A 


URAJND 


8 


N/A 


N/A 


lODE 


8 


N/A 


N/A 


C_RS 


16(1) 


2-' 


Meters 


DELTA_N 


16(1) 




semi- 
circles/ sec 


MO 


32(1) 


2-3. 


semi-circles 


C_UC 


16(1) 


2-^' 


Radians 
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ECCENTRICITY 


32 


2-33 


N/A 


C US 


16(1) 


^-29 


XxcLLilCLL 1 0 


A SORT 


32 


z 


^| meters 


lUlif 


15 


2* 


Seconds 


C_IC 


16W 


2-29 


Radians 


OMEGA.O 


32(1) 


2-31 


semi-circles 


CJS 


16(1) 


2-29 


Radians 


ANGLE JNCLINA 
TION 


32(1) ' 


2-31 


semi-circles 


C_RC 


16(1) 


2-^ 


Meters 






2 


semi-circles 


OMEGADOT 




2-43 


semi- 

Circles/ sec 


IDOT 


16(1) 




semi- 
circles/sec 


TOC 


16 


2^ 


Seconds 


T_GD 


8(1) 


2-31 


Seconds 


AF2 


8(1) 


2-55 


sec/sec^ 


AFl 


16(1) 


2-^^ 


sec/ sec 


AFO 


32(1) 


2-31 


Seconds 




ALM_DATA_FLAG 


8 


N/A 


N/A 


ALM_WEEK_NUM 


16 


N/A 


N/A 


The structure shall include 32 occurrences of the following record of 
almanac parameters / 


ALM_VALID_FLA 
G 


8 


N/A 


N/A 


ALM_SV_PRN_NU 
M 


8 


N/A 


N/A 


ALM_ECCENTRIC 
ITY 


16 


2-2. 


dimensionles s 


ALM_TOA 


8 


2'^ 


Seconds 


ALM_DELTA_INC 
L 


16(1) 


2-19 


semi-circles 


ALM_OMEGADOT 


16(1) 


2-38 


semi- 
circles/sec. 


ALM_A_SQRT 


24 


2-" 


metersi/2 


ALM_OMEGA_0 


24(1) 


2-23 


semi- circles 


ALM_OMEGA 


24(1) 


2-23 


semi-circles 
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ALM MO 


24(1) 


2-^ 


semi-circles 


ALM AFO 


16(1) 


2-20 


Seconds 


ALM_AF1 


16(1) 


2-3« 


sec/ sec 



Table 7- Horizontal/ Vertical Error 



Values 


Position Error (in meters) 


QxOO 


<1 meter 


0x01 


<5 meters 


0x02 


<10 meters 


0x03 


<20 meters 


0x04 


<40 meters 


0x05 


<80 meters 


0x06 


< 160 meters 


0x07 


No Maximum 


0x08 - OxFF 


Reserved 



Table 8- Time/accuracy priority 



TIME_ACC_PRIORI 
TY 


Description 


0x00 


No priority imposed 


0x01 


RESP_TIME_MAX has priority 
over 

HORI_ERROR_MAX/VERT_ERR 
OR MAX 


0x02 


HORI_ERROR_MAX/VERT_ERR 
OR_MAX has priority over 
RESP TIME_MAX 


0x03 - OxFF 


Reserved 



Table 9-ALM_REQ_FLAG Description 



Value 


Description 


0 


No almanac request (default) 


1 


Report flash Almanac age (message sent back even 
with no position) 


2 


Request Almanac Collection from SV 
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3 


Report Almanac Update Status 


4 - FF 


Reserved 



AI3 Response message 

Amongst other things the SLC reports MS position resiilts and Almanacs reference time 
in the format specified in Table 10. 



Table 10 - AI3 Response Message Before Compression 



Field 


LengtlMbits) 


POS RESULTS_FLAG 


8 bits 


POSITION_ERROR_ STATUS 


8 bits 


POS ACC_MET 


8 bits 




POS TYPE 


8 bits 




DGPS COR 


8 bits 




MEAS_GPS_WEEK 


16 bits 


POSITION 

MAIN 

SECTION 


MEAS_GPS_SECOND 
S 


32 bits 


MEAS_LAT 


32 bits 


MEAS_LONG 


32 bits 


OTHER SECTIONS 


8 bits 


Following sections are always present, but their validity depends on the 
value of OTHER SECTIONS 


HORIZONTAL 

ERROR 

SECTION 


ER_EL_ANG 


8 bits 


MAJ_STD_ER 


8 bits 


MIN STD_ER 


8 bits 




VERTICAL 
POSITION 
SECTION 


HEIGHT 


16 bits 


HEIGHT_STD_ER 


8 bits 




VELOCITY 
SECTION 


HOR_VEL 


16 bits 


HEADING 


16 bits 


VER VEL 


8 bits 


VEL_ER_EL_ANG 


8 bits 


VEL_MAJ_STD_ER 


8 bits 


VEL_MIN_STD_ER 


8 bits 


VER_VEL_STD_ER 


8 bits 
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CORRECTION 


1 llVlilf^rCIlfP 


ft Kite 


SECTION 


CLK_BIAS 


16 bits 




CLK_DRIFT 


16 bits 




CLK_STD_ER 


8 bits 




UTC_OFF 


8 bits 






NB SV 


8 bits 


POSITION 

CORRECTION 

SECTION 


Two following fields are repeated 10 times, only the first 
"NB.SV" fields are vaHd. 


SV_PRN 


8 bits 




C_NO 


8 bits 




INV_WEIGHTS 


8 bits 




ALM REF DATE FLAG 


8 bits 


ALM_DATA_ST 
AT 


8 bits 


ALM_WEEK_N 
UM 


16 bits 


ALM_TOA 


8 bits 



ACK/NACK Message 



The ACK/NACK Can be either sent by SLC (in response to a message from 
CP), or by CP (in response to a message from SLC). 



Table 11-ACK/NACK Message format 



Field 


Length (bits) 


ACK/NACK 


8 
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Message Procbssino Procedures 



General Overview 

The AI3 Request and Response are defined as large data structures. 
Those messages will be prabably implemented by using a memo^ 
mirroring mechanism. For every messs^e, the same memory structiire is 
defined on the CP and SLC sides. 
.One set of memory is defined per direction. 

The transmission of the information in one implementation is simply a 
"read, compression, and transmission byte-by-byte" of the full structure on 
the transmitting side. The same data structure on the receiving side is 
filled out byte-by-byte as soon the information arrives and is 
decompressed. 

The CP shall send the AI3 Request message at the opening of the "AIS" 
session, even when the AI3 data structure has not been updated. Hie SLC 
shall use the validity flags in the data structure itself to determine what 
information is relevant. The compression mechanism drastically reduces 
the transmission time of the empty sections of the message. 

In a preferred embodiment. Neither SLC, nor CP shall send any AIS 
message before a Session Opening Request/ Response pair of "AIS" type, 
or after a Session Closing Request/ Response pair have been exchanged 
over the "F" interface. 

For every message received, an ACK or NACK message is returned, to 
speed up the repetition of the message if improperly received. This 
mechanism is intended to be used on a local serial link, and has no 
strong error detection and correction mechanism. It should not be used 
over-ttie-air in any circumstances. 
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SLC Procedures 

SIiC Reception Procedures 

• Upon receiving an AI3 Request message after an AI3 session is open, 
the SLC shaU examine the received AI3 message. If the AI3 message is 
transported in several packets, the SLC wiU need to reassemble the 
segmented data. After receiving all packets of an AI3 message correctly 
the SLC shall decompress the reassembled data and copy it to the 
structure on the SLC side. 

• Upon receiving an AI3 messe^ before an AI3 session is open, the SLC 
shall silently discard the message. 

• If a segment data is missing, the whole message shaU be discarded. 
SLC Tr»"««"*««*on Procedure 

• Regardless of the tune set by MAX_RESP_TIME field found in the AI3 
Request, upon completing a position fix, the SLC shall send an AI3 
Response providing the position fix, with POSITION.RESULTS FLAG 
set to 'r (valid position section) and POSITION.STATUS set to 0 
(valid position). 

• Upon timeout of the MAX_RESP_TIME field found in the AI3 Request, 
and no position fix yet, SLC shall send an AI3 response message with 
POSITION_RESULTS_FLAG set to '1' (valid position section) and 
POSITION_STATUS set to "Need More Time", 

• Upon reaching the end of the GPS search domain, and with no 
position found, SLC shall send an AI3 response message with 
POSlTION_RESULTS_FLAG set to '1* (valid position section) and 
POSITION_STATUS set to "No fix available after full search". 

• If the SLC needs more Aiding data (Ephemeris only), SLC may send an 
AI3 response message with POSITION_RESULTS_FLAG set to 1 (vahd 
position section) and POSITION.STATUS set to "GPS Aiding data ^ 
missing. 

• Optionally, and according criteria to be defined on a case by case, the 
SLC may add an Almanac reference date section in any AI3 Response 
message. This capabiUty is meant to allow the CP to evaluate the age 
of the almanacs in the SLC, and possibly to replace them by a newer 
one, by an AI3 Request message. 
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CP Reception Procedures 

• Upon reception of an Air Interface Protocol Message (or a group thereof), 
the CP shaU fill (while reformatting if necessary) the relevant fields of 
the "AI3 data structure" on the CP side, using the received Air-Interface 
Message information. If an AI3 session is cxirrently open, the CP shall 
send the AI3 Request message v^rhen the information or part of it has 
been updated in the CP structure without any request. 

• Upon reception of an AI3 Response message, the CP shall examine the 
received AI3 message. If the AI3 message is transported in several 
packets, the CP will need to reassemble the segmented data. After 
receiving all packets of an AI3 message correctly the CP shall 
decompress the reassembled data and copy it to the structure on the 
CP side. 

• Upon receiving an AI3 message before an AI3 session is open, the CP 
shall silently discard the message. 

• If a segment data is missing, the whole message shall be discarded. 

CP T«»"«»"^'»»ion procedures 

• Within 2 seconds after the Session Opening Notification Message 
with the SESSION_OPEN_STATUS field set to Session Opening 
Succeeded is received (See Ref 2). the CP shall start to send the AI3 
Request message regardless whether it has vaUd aiding information or 
not. The AI3 Request shall be compressed and only the compressed 
data stream shall be sent to the SLC. If the size of the compressed data 
stream is larger than the maximum, it shall be segmented into several 
data packets. The data packets shall be sent sequentially in the order 
they have been segmented. 
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Exception procedures: 

For £in AI3 Request message from CP to SLC: 
CP side 

-When CP sends an AI3 Request message, it expects an ACK or a NACK 
back from the SLC, within 3 seconds after transmission of the message. 
-If CP does not receive anything within 3 seconds, it shaU send again the 
AI3 Request. It can repeat the sequence up to three times. After the 3 
times repetition, the CP shall close the AI3 channel. 
-If CP receives a NACK it sends immediately the same message agam. 
After three repetitions, the CP shall close the AI3 channel. 

SLC side 

-As soon as the SLC receives the message from CP and decodes it 
properly, it sends an ACK within 3 seconds of the reception. If the 
message caimot be decoded properly, SLC sends a NACK within 3 

seconds • 

-If segments of a same message are received out of order, the SLC throws 
away the segments already received, ignores the remaining segments and 
sends a NACK within 3 seconds. 

For an AI3 Response message fr om SLC to CP: 
SLC side 

-When SLC sends an AI3 Response message, it expects an ACK or a 
NACK back from the CP, within 3 seconds after transmission of the 

message. . - 4.1, 

-If SLC does not receive anything within 3 seconds , it sends again the 
AI3 Response. It can repeat the sequence up to three times. After the 3 
times repetition, the SLC shall stop sending the message. 
-If SLC receives a NACK it sends immediately the same message agam. 
After three repetitions, the SLC shall stop sending the message. 

CP sid& 

-As soon as the CP receives the message from SLC and decodes it 
properly, it sends an ACK within 3 seconds of the reception. If the 
message cannot be decoded properly, CP sends a NACK within 3 
seconds. After three repetitions, the SLC shall stop sending the message. 
-If segments of a same message are received out of order, the CP throws 
away the segments already received, ignores the remaining segments and 
sends a NACK within 3 seconds. 
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Special Procedures 

Update in Flash from Network 

This procediare will be followed when the CP has received valid almanac 
from the network and wants to update the almanac in SLC's flash: 

1) -CP sends an "AI3 request message" with ALM^REQ^FLAG set to "0", 
and ALM_DATA_FLAG set to "l*" and valid almanac information in the 
Almanac section. 

2) -SLC stores the almanac data in the RAM as soon as it gets the AI3 
request message 

3) -When the CP closes the AI3 session from the F interface, SLC 
transfers almanac information from RAM to FLASH: 

-If the transfer of almanac from RAM to FLASH has been successful, 
the SESSION_CLOSE_STATUS in "Session Closing Notification 
message'' Close session in F interface will be set to ''Session Closed". 

-If the transfer of almanac from RAM to FLASH has failed, the 
SESSION_CLOSE_STATUS in ''Session Closing Notification message" 
Close session in F interface will be set to "Session Closing Failed'*. 

Update Almanac from SV 

This procedure will be followed when the CP wants to force the SLC to 
collect new almanac and update the almanac in SLC's flash with 
collected almanac: 

1) -CP sends an AI3 request message with ALM.REQ^FLAG set to '*2" 
(Request Almanac Collection from SV), and ALM_DATA„FLAG set to 
"0" and no Almanac section 

2) -Upon reception, SLC will tiy to collect almanac data from broadcast 



3)-To check on the progress, CP periodically sends AI3 request message 
with ALM„REQ_FLAG set to "3" (Report Almanac Update Status). 

Upon reception of the update status request message, SLC shall 
immediately send and AI3 response message with: 

ALM_DATA„STATUS set to "1" if SLC is searching for satellites, 
and not collecting any NAV message 
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ALM_DATA_STATUS set to "2" if SLC tracks at least one satellite 
strong enough to collect data, and is actuaUy collecting data 
ALM_DATA_STATUS set to "3" if SLC has gone through a full 
search sequence and has not found any satellite suitable for data 

collection ^ , , „ , 

ALM_DATA_STATUS set to "4" if SLC has collected a full almanac 

and ALM_WEEK_NUMBER and TOA either from RAM-stored or 
FLASH-stored almanac according to the table Error! Reference 
source not found.. 

4)-When the CP closes the AI3 session from the F interface, SLC 
transfers almanac information from RAM to FLASH: 
-If the transfer of almanac from RAM to FLASH has been successful, 
the SESSION_CL0SE_STATUS in "Session Closing Notification 
message" Close session in F interface will be set to "Session Closed". 
-If the transfer of almanac from RAM to FLASH has failed, the 
SESSI0N_CLOSE_STATUS in "Session Closing Notification message" 
Close session in F interface wiU be set to "Session Closing Failed". 

Note 1: If no full almanac was collected dxiring the session ( and the 
ALM_DATA_STATUS was never found to "4" during step 3), the 
SLC won't try to transfer the incomplete almanac from RAM to 
FLASH. The SESSION_CLOSE_STATUS in the "Session 
Notification message" will be set to "Session Closed". 

Note 2: A full almanac collection cycle will take a Uttle bit less than 13 
minutes. The CP should not expect to receive an 
ALM_DATA_STATUS set to "4" before such a time elapsed smce 
the first time ALM_DATA_STATUS has been found set to "2". 
Check Affe of Ahp "*"*" FI,ASH 

When an AI3 session is open, the CP can check at any time what is the 
s^e of the almanac currently in flash. 

1 

1) -CP sends an AI3 request message with ALM_REQ_FLAG set to "1", 
and ALM_DATA_FLAG set to "0" and with no Almanac section 

2) -Upon reception of the age of almanac request message, SLC shall 
immediately send and AI3 response message with ^ ^ 
ALM_DATA_STATUS set to "0" and ALM_WEEK_NUMBER and TOA 
from FLASH-stored almanac. 
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S pecial Cases 

If CP sends an AI3 request message with both POS_REQ_PIAG and 
ALM_REQ_FLAG set to "1" response will be undefined. 

[00092] While various embodiments of the invention have been described, it will be 
apparent to those of ordinary skill in the art that many more embodiments and 
implementations are possible that are within the scope of this invention. 
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Claims 



What is claimed is: 

1 . An interface for Satellite Positioning Systems comprising: 

a inter&ce; 

a radio section on a handset; and 

a Satellite Positioning Systems on the handset in signal communication with the 
radio section via the interfeice. 
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Estimated Position Error (EPE) 

1. What is EPE? 

GPS equations are defined by GPS measurements from four or more GPS 
satellites and lines of sight to the corresponding GPS satellites (also called 
satellite geometry). There are variety of errors exist in the GPS measurements 
and when the GPS equations are solved, these measurement errors are 
amplified by satellite geometry to give rise to an error in the estimate of position. 
When an estimator solves GPS equations It also produces an estimate of error In 
position. This position error estimate is defined as EPE. 

The EPE reports the eaors in three dimensions (3D) and It can be fully 
represented by a 3D confidence ellipsoid (an ellipsoid inside which one can 
expect to find the true position with some levels of confidence). However, it is 
often convenient to give partial specification of EPE in the local horizontal plane 
and along the local vertical direction; in the local horizontal plane the EPE is 
specified by a 2D confidence (or error) ellipse; in vertical direction It is specified 
by a confidence (or error) inteival. 

It is to be noted that the EPE Is inferred by using a statistical model of 
measurement errors. At times this statistical model is not a good representation 
of the measurement errors to which the receiver is subjected in real time and in 
such cases the EPE is prone to significant uncertainties. 

2. How is EPE reported In SiRF receivers? 

In SiRF receivers the EPE is reported by parameters of horizontal error and 
vertical error. For the horizontal error these are (1) confidence ellipse parameters 
of semi-major axis. (2) semi-minor axis and (3) the acute angle subtended by the 
semi-major axis with the local north. For the vertical en^or it is error magnitude 
(fig. 1). The ellipse is positioned on the estimated position and can be thought of 
as a region estimate (as against the usual point estimate) of the position in the 
horizontal plane. The magnitude of the vertical error, when added and subtracted 
from the estimated position along the vertical line, defines a segment, which can 
be thought of as an interval estimate of the position along the vertical line. There 
will be a percentage of chances that the true position may lie inside the ellipse in 
the horizontal plane and inside the interval along the vertical line depending on 
the associated confidence level. This Is true for each reported position. For 
example fig. 2 shows two ellipses and two vertical Intervals centered at estimated 
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positions P1 and P2 (note that even if true position is stationary, the PI and P2 
in general are different). The ellipses may or may not overlap with each other. 
Similarly the segments may or may not overlap with each other. The orientations 
and sizes of ePipses and lengths of the intervals depend on satellite geometry 
and on the parameters of error models used by the estimator, which solves the 
GPS equations. 

3. Confidence levels 

Error in estimate of position Is a random variable. If random measurement errors 
have a Gaussian distribution then the error In the estimated position also has 
Gaussian distribution. This Gaussian distribution is a three dimensional (3D) 
distribution, which includes the single dimensional (1 D) Vertical Position Error 
(VPE) random variable and the two dimensional (2D) Horizontal Position Error 
(HPE) random variable. 

The standard deviation of the 1 D VPE is the 1-sigma value of the error. An r> 
Sigma value of the VPE is simply n times its 1 -sigma value. Along the vertical line 
it is expected that the vertical component of the tme position is found 68.27% of 
the time in the +/-1-sigma VPE interval centered at the estimated position, 
95.45% of the time in the +/- 2-sigma interval and 99.73% of the time in the 3- 
Sigma Interval. The percentage confidence is called confidence level. The 
corresponding n values (in rhsigma) are called confidence or sigma coefficients. 
In summary, for the VPE, the relationship between the sigma coefficients and the 
confidence level are defined as: 1-sigma <=> 68.27%, 2-sigma « 95.45% and 3- 
sigma o 99.73%. 

For the 2D HPE, the confidence intervals become confidence ellipses and the 
percentage confidence levels are different from 1D to 2D. In 1D, there Is only one 
line along which the confidence interval is considered. In 2D, there are two axes, 
say local north axis and local east axis and these two axes specify infinitely many 
lines in the horizontal plane and infinitely many standard deviations and intervals; 
with standard deviation along a line depending on the inclination of the line. It 
turns out that the locus of the end points of all such intervals is an ellipse; it is 
called as the confidence ellipse. Along the line of semi-major axis the length of 
the interval Is maximum, whereas along the semi-minor axis it Is minimum. If 1- 
sigma intervals are considered then one gets 1-sigma ellipse, if 2-sigma intervals 
are considered then one gets 2-sigma ellipse and so on. Semi-major axis of n- 
sigma ellipse is n times semi-major axis of 1-sigma ellipse, so is the case with 
semi-minor axis and angle orientation of n-sigma ellipse is the same as angle 
orientation of 1-sigma ellipse. In the horizontal plane it is expected that the 
horizontal projection of the true position to be found 39.4% of the time in the 1- 
sigma HPE ellipse centered at the estimated position, 86.5% of the time in the 2- 
sigma ellipse and 98.9% of the time in the 3-sigma ellipse. It is not necessary to 
have n in rvsigma as integer. One can specify percentage confidence to get 
corresponding sigma coefficient, for example, for 95% confidence level, 1D 
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Sigma coefficient is 1 .96 and 2D sigma coefficient is 2.45. Table 1 shows different 
Sigma coefficients; it also includes the 3D case. 

Table 1 - Signal Coefficients vs. Designed Confidence Level 
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The confidence percentage gives a percentage of times connponents of true 
position lie inside the HPE ellipse or the VPE interval centered at estimated 
position. Equivalently, this is nothing but percentage of times components of an 
estimated position lie inside HPE ellipse or VPE interval to be centered at true 
position. 

4. EPE verification on a SiRF receiver 

The confidence percentage gives a means of verification of EPE. For a specified 
confidence percentage, a sample of large size is gathered and the percentage of 
times the true position lies inside the HPE ellipse and Inside the VPE Interval is 
determined. If these percentages are close to the specified percentage 
confidence levels within some tolerance then the EPE is verified. The question to 
be answered is: How large should be the sample size or equivalently how large 
should be the duration of data collection? 

It is hopeless to try to evaluate performance of the EPE by collecting data for just 
few hours. This is because that some measurement error components have a 
very long latency period (period required for the error to average out to zero). 
Notable among these components are errors due to the residual signal 
propagation delays in ionosphere and troposphere, and in satellite clock and 
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ephemeris. These are the long-term error components as against the short-term 
error components such as the receiver measurement noise and the multi-path. 
Table 2 shows the 1-sigma values of these various error components along with 
their orders of latency periods under the open sky and non-reflective environment 
conditions. 



Table 2-1 Sigma Values and Latency Period for Position Error Components 



Error component 


1 -Sigma value in meter 


Order of latency period 


Receiver noise 


0,5 


Seconds 


Multi-path 


1 


Minutes, 


Residual ionosphere 


4 


Days 


Residual troposphere 


0.2 


Days 


Satellite clock 


2 


Days 


Satellite ephemeris 


2 


Days 



The long-term errors when viewed over a short period appear as biases rather 
than random fluctuations around zero. If over a period, the satellite geometry and 
signal conditions are almost constant for a stationary receiver then the HPE 
ellipse and VPE interval will also remain constant. In this case, it is possible to 
construct the HPE ellipse and VPE interval to be centered at the true position. It 
can be seen from fig. 3 that the errors due to long term error components in the 
measurements show a cbud of points away from the true position. If the HPE 
ellipse and VPE interval remain constant then this cloud will be spread evenly 
after a long time. However it is not possible to see this effect because the HPE 
ellipse and VPE interval will not remain constant due to changes in satellite 
geometry and the signal conditions but the scenario provides help in visualization 
of the effects of long temri error components in the measurements. 

The above scenario also provides some insight into the difficulty of the EPE 
verification due to the change in satellite geometry. If there are distinct satellite 
geometries and in the period of verification and some or all geometries do not 
have even spreads of the corresponding error clouds then the percentage values 
detemnined for the HPE and VPE are prone to uncertainty. 

Yet another difficulty in the EPE verification arises due to the mismatch between 
the statistical modeling of the measurement errors used in EPE calculation and 
the actual measurement errors to which the receiver is actually subjected in real- 
time. For example, the EPE is calculated based on nominal multi-path 
measurement error modeling but the actual receiver might be subjected to 
considerable multi-path. 

Finally the EPE calculation is based on the assumption that the errors of both the 
long term measurement and the short term measurement have a Gaussian 
distribution. Deviation from this assumption can occur in the real-time test 
scenario and can cause further uncertainties in the EPE. 
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5. SiRF EPE computations 
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1 Scope 

This document is to guide the customer's CP software implementer to design the IS801 
to AI3 protocol translation layer. To identify which messages in the IS801 are relevant 
(request and response), and how to map them into the AI3 and F interface. 

The recommendation to be presented in this document can be implemented even by a 
non-GPS specialist. 

This document only presents a recommended implementation for the customers to 
implement the AI3 architecture inside the CP software, but by no means represents the 
only implementation approach. 

2 System Overview 

The mobile station consists of a CP and a SLC. The CP refers to the dedicated hardware 
and software to establish and manage wireless communication with the base station. 
The SLC refers to the GPS section to receive GPS signals and determine the mobile 
station geographic location. It is composed of the "Aidmg-Independent-Interoperability- 
Interface" layer, to dialog with the CP, on top of the SiRF GPS core technology. 

Whereas SiRFLoc encompasses several architectures; the only one for which AI3 
interface shall be used is the "Aiding Independent Interoperability Interface 
Architecture". The CP implements the Geolocation air-interface protocol (from 
Geolocation Server to CP) and then passes GPS aid information received from the base 
station to the SLC, over the A13 as shown in Figure 1 




Figure 1 - Wireless Mobile Position System Architecture - AI3 Architecture 



Information Proprietary to SiRF Technologyt Inc. 



■6- 



^^^mPLoc: IS-801 Protocol to SiRFLoc AI3 Implementation Guidelines Rev 1.1 

Table 1 describes the interfaces shown in Figure 1. There are different geolocation 
standards developed for different types of wireless networks; anyone can be the "H" 
interface. 



Table 1 Interface Description 



Inter&ce 


Functional 
Entities 


Protocol 


Description 


U 


Geolocation 
Server-CP 


Air-interface 


Various geolocation standards. 
Controlled by the CP manufacturer. 


F 


CP-SLC 


SiRFLoc 
Specific 


SiRFLoc Client Interface Control 
Document 


G 


CP-SLC 


SiRFLoc 
Specific 


SiRFLoc AI3 interface Control Document 



The F interface, which is the client system interface between SLC and CP, is defined m 
SiRFLoc Client Interface Control Document. It acts as a bootstrap protocol, ever present, 
allowing the CP to choose at run-time between an air-interface (case of the end-to-end 
system architecture) or the AI3. It is designed to perform the following tasks: 

• SLC hardware management from the CP (power on/off, reset); 

• If available, implicit aiding interface, i.e. time and frequency transfer from 
network (or from CP real time clock) via the CP, and approximate position (from 
the network, if it does exists); 

• Session opening/ closing (i.e. notifying the SLC that an air-mterface connection 
has been opened/ closed); 

• In a dual-mode MS, notifying the SLC what air interface is on, and thus 
notifying the SLC what set of geolocation air-interface protocol to use to dialog 
with the SLS; 

• Interfaces locally with the CP to allow the user to locally trigger a geolocation, 
and to report the position for display or usage at the MS; 

• Convey the position results to the CP. 

In the "Aiding Independent Interoperability Interface Architecture", it is the CP 
developer's responsibility to implement the Geolocation protocol that is used between 
the Geolocation Server and CP. The G interface is used to convey GPS aid information 
received from the base station to the SLC. 

This ICD defines the G interface. Since there are many existing Geolocation protocols, 
the G interface is designed to be usable over a large range of Geolocation standards and 
air-interface independent, i.e. it is umque for applicable air-interfaces. The "A13" is 
actually a reduction of the applicable GeolocaUon standards. It will not be optimized for 
any of them. 
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Since the "G" interface will be always used together with the F interface, all information 
already accessible over the "F" interface is not duplicated in this AI3 interface. This 
prevents a lot of confusion created by the message duphcation It also simplifies the 
AI3, as only the air interface information is sent over the AI3. 

All Geolocation protocols, includmg SAMPS, GSM. and CDMA, work under the 
interaction paradigm. The base station sends back only what the mobile station has 
requested. The strategy to perform the mteraction is highly dependent on the knowledge 
on the SLC proccssmg. Only the SLC can optimal implement the strategy part. 

For ease of use, the AI3 supports only one single form of aiding - ephemeris aiding. The 
interaction between SLC and CP required for performing the mteracUon strategy, is 
eliminated by "canning" the requests. The "canned requests" are a subset of requests 
picked from the Geolocation protocol at design time and will be systematically sent to 
the Geolocation Server. No control on the mteraction can be applied by the SLC, The CP 
passes the aid data through AI3 without any request. The SLC cannot stop it or tailors 
it. Since the protocol interactivity is broken, the performance won*t be optimal.. 

AI3 is an interface, not a protocol. There is a fundamental difference between an 
interface and a protocol. /The protocol is an interactive process, where the information is 
expliciUy requested and explicitly answered. Only the information really needed is 
requested. The mechanism of error detection and request for repetition is quite 
sophisticated. On the other hand, the interface does not imply any mteraction between 
the two interfaced entities. All information has to be part of the message. There is no 
need for a sophisticated error correction scheme, and the size of the message can be 
quite large. 



The AI3 shall be used exclusively 'between CP and SLC over a serial connection in the 
mobile station. It shall not be used over the air as the volume of exchanged information 
is quite significant. 
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to TIME_REF_CDMA 
conversion in 8.4.1 



-Corrected 
HEIGHT(PosiUon 
Results Message) to 
HEIGHT(IS801) 
conversion in section 
8.4 



4 Glossary 

2D Position. A two-dimensional (latitude and longitude) position. 

3D Position. A three-dimensional (latitude, longitude, and height) position. 

Aiding Independent InteroperabiUty Interface (AI3). Generic aiding interface 
between CP and SLC, independent from the actual Geolocation protocol between 
Geolocation Server and CP- 
Aiding Data. The data provided by the base station to the mobile station for various 
purposes (e.g., acquisition, location calculation or sensitivity improvement). 
Generic Geolocation Server Station. This term refers to the entity in the network 
which provides aid (GPS-related or other) information to the SLC, and retrieves the 
position results. It has different names depending on the cellular platform of interest 
(PDE for 18801, GMLC for GSM,...) 

Call Processor (CP). The dedicated hardware and software to establish and manage a 
wireless radio connection. 

Bphemeris. The ephemeris data aire embedded in the GPS Navigation Message. The 
precise (high accuracy) orbital parameters of one GPS satelhte, as transmitted by that 
satellite m the GPS Navigation Message Subframe 1, 2, and 3. The ephemeris also 
includes satellite clock correction. 

Geolocation. The process of determinmg a geographic location. 

GPS. Global Positioning System. 
ICD. Interface Control Document. 

Mobile Station fVIS). It consists of a CP and a SLC, communicates with the base 
station and receives GPS signals. 

SiRPI/OC Client (SLC). The SiRFLoc GPS section embedded in the mobile station. It is 
composed of a protocol layer, to dialog with the CP and SLS through the CP, on top of 
the SiRF GPS core technology (hardware and software) 

SV. Space Vehicle or Satellite. 
5 References 

Ref 1 - ICD-GP§-200C, Navstar GPS Space Segment/ Navigation User Interfaces, 
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September 1997 

Ref 2 - SiRFLoc Client Interface Control Document, Rev 1.3, January, 2001 

Ref 3 - Aiding Independent Interoperability Interface Control Document, Rev 1.0, 
October 30, 2000 

Ref 4 - TIA/EIA/IS-801 Position Determmation Service Standard for Dual-Mode Spread 
Spectrum Systems, October 15, 1999 



6 Aiding Data and Their Logical Channels 

Table 2 summarizes -the aidmg data to be required by SLC for MS position computation 
in the network aided operation mode. Among them, the Ephemeris data and MS 
Position Request Parameters will be obtained via the IS-801 protocol messages and 
need to be converted into the AI3 data structure before passing to the SLC via the G 
interface channel. The SLC will obtain the remaining data via the F mterface. 

The approximate MS position data can be obtained either via an 18-801 message or 
implicitly via an IS-95 message. The CP will get very precise GPS time from the BS via 
the IS-95 Sync Channel Message. The GPS time of SLC will be synchronized with the 
GPS time of CP via the time transfer method as described in Ref 2. The crystal 
frequency of SLC will be synchronized with the CP clock frequency via the frequency 
transfer method as described in Ref 2. 



Table 2- Aidmg data source for SLC 



Data Type 


Source 


Logical 
Channel 


MS Position Request 
Parameters 


IS801 message: Request Location Response 
(BS to MS) 


G[AI3] 


Ephemeris 


IS801 message: Provide GPS Ephemeris (BS to 
MS) 


G(AI3) 


Approximate MS 
Position 


IS801 message: Provide Base Station Almanac 
(BS to MS) 

OR 

IS-95 Implicit Aiding: Paging Channel ''System 
Parameter Message" (BS to MS) 


F (client 
system) 


GPS time 


IS-95 Implicit Aiding: Sync Channel "Sjmc 
Channel Message" (BS to MS) 

AND 

Time Transfer method 


F (client 
system) 


Frequency 


IS-95 Implicit Aiding: a method to find out the 


F (client 
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frequency ofTset between BS and CP. 


system) 




AND 






Frequency Transfer method 





7 £5-801 Handset Design Concept with AI3 

The purpose of the AI3 concept is to make the SLC based handset to work with any 
geolocation air-interface protocol for network aided data without SiRFLoc Server. The 
current AI3 architecture only supports the network aiding with Ephemeris data. 

Figure 2 shows the high level architecture of AI3 to be implemented mside the IS-801 
based CDMA handset. The CP shall communicate with the SLC via a RS232 Imk and 
hardware Unes (for the time and frequency transfers) as described in Ref 2. The F and 
G are two separate logical channels for the RS232 interface. The G interface is designed 
to pass the A13 aiding data to SLC, The rest of the aiding data will be passed to SLC via 
the F interface. On the SLC side, the F interface is a standard SiRFLoc client interface 
and the G interface is transparent to any standard air-interface protocols. For the IS- 
801 CP, the AI3 data will be generated via an "IS-801 message to AI3" converter. The 
AI3 data will be packed into the G message format via an AI3 interface message handler 
before passing to SLC via the RS232 link. The CP shall obtain the time, location and 
frequency data from appropriate air-interface messages (see Table 2). The location data 
will be passed to SLC via a "F" interface message (Approximate MS Position Response 
message) as described in Ref 2. The Ume and frequency data will be passed to SLC via 
the time and frequency transfer methods as described in Ref 2. 




Figure 2 - AI3 Architecture in the CDMA handset 

The AI3 data structure contains information on ionospheric, satellite ephemeris and the 
MS position request parameters*. All of these data are byte oriented. The AI3 data 
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structure needs to be reset to 0 after the CP established a communication link with the 
BS. 

7. 1 Source of Aiding Data 

7.1.1 Approximate MS PosiUon 

The BS position can be used as the approximate MS position. There are two ways to get 
the BS position data: 

1. IS-95 implicit message 

The IS-95 Paging Channel "System Parameter Message" contains the BS position 
data of longitude and latitude. Since the altitude data is not available in this 
message, therefore the altitude of the approximate MS position wiU be set to 0. 

2. IS-801 protocol messages 

The CP may also get the BS position data via the IS-801 "Provide Base Station 
Almanac" message. This message contains sufficient data, which can be used to 
compute the longitude, latitude and altitude of the BS. In this method, the CP 
will need to send the'lS-801 "Request Base Station Almanac" message before the 
PDE can respond with the "Provide Base StaUon Almanac" message. This 
requires addiUonal message handling compared to the IS-95 implicit method. 

7. 1.2 Location Request Parameters 

The IS-801 " Request Location Response" message provides data to compute the 
number of fixes and time between fixes for AI3 location request parameters. 
Other location request parameters will be set to values as described in section 
8.4. 

7. 1.3 Ephemens Data 

The IS-801 "Provide GPS Ephemeris" message provides all data to be converted 
to the ephemeris data for AI3. 

7.1.4 GPS Time 

To reduce the GPS time uncertainty, the SLC shall synchronize the GPS clock 
with the CDMA system clock via the time transfer method as described in Ref 2. 
The CP shall synchronize the handset clock with the CDMA system time, which 
can be obtained from the CDMA Sync Channel "Sync Channel Message". 

7.1.5 Frequency 

To reduce the GPS frequency uncertainty, the SLC shall synchronize the GPS 
clock with the CP and BS clock via the frequency transfer method as described 
in Ref 2. 
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7.2 Process of Aiding Data 

The CP call processing software shall handle the communication with the BS for 
network aiding data via the IS-801 and IS-95 message protocols. This section 
presents the general description for processing the aiding data. Section 9 
provides the detealed description of the method to convert the data from IS-801 
messages to AI3 structure. 

7.2. 1 Process of AI3 Data 

The AI3 Data consist of MS position request parameters as well as the ephemens 
aiding data. The CP may compute the MS position request parameters by using 
the number of position fixes data to be retrieved from the IS-801 "Request 
Location Response" message. The CP shall generate the ephemeris aiding data in 
AI3 format by retrieving the compressed ephemeris data from the IS-801 "Provide 
GPS Ephemens" message. The CP shall store the MS position request parameters 
and the ephemeris aiding data into the AI3 data structure. 

7.2.2 Process of the Approximate MS Position Data 

The CP may use the BS position data as obtained from the IS-95 "System 
Parameter Message" during the MS Idle State and used it as the approximate MS 
position. Due to the lack of altitude information of the BS m the IS-801 "System 
Parameter Message", the CP shall set the altitude of the approximate MS position 
to 0. 

The CP may choose to obtain the BS position data from the IS-801 "Provide Base 
Station Almanac** message. By choosing this method, the CP needs to send the 
IS-801 "Request Base Station Almanac" message during the MS System Idle State 
or MS Control on the Traffic Channel State. Comparing to the implicit IS-9S 
method, this method requires the processing of two IS-801 messages and with 
time delay - later than MS Idle State. Among the multiple BS coordinates found 
in the "Base Station Almanac" message, the CP shall pick upthe BS with which it 
has the direct radio connection as the reference BS for the approximate MS 
position. 

7.2.3 Process of the GPS Time Data 

The CP uses the CDMA system time as obtained from the IS-95 "Sync Channel 
Message" as the CP time. The CP sends timing information to SLC via the time 
transfer method as described in Ref 2. 

7.2.4 Process of the Frequency Data 

The CP shall synchronize its' clock frequency with the SLC GPS frequency via the 
frequency transfer method as described in Ref 2. 
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7.3 Transfer of Aiding Data 

The CP shall send the AI3 data to SLC via the G interface -A13 Data Message «. The G 
interface is described in Ref 3. The CP shall send the approxiraate MS position, time 
and frequency transfer data via appropriate F interface messages. The F interface is 
described in Ref 2. 

7.4 Sununary of IS-95 and IS^Ol Messages for AI3 AppUcation 



Table 3 IS-95 and IS-801 Messages for AI3 AppbcaUon 



Messages 


Typ 

IS-95 


e 

IS-801 


Purpose 


Sync Channel Message 


BS to CP 




Provide the CDMA system 
time (GPS based). 


System Parameter Message 


BS to CP 




Provide BS position for 
approximate MS position. 


Request MS Information 
(see Ref 4, section 4.2.4) 




PDE to CP 


Ask tne v^Jt capaoiiiiy 


Provide MS Information 
(see Ref 4, section 3.2.4.2) 




CP to PDE 


1 ell rUCd Uiai iVLO la i-rcipdUlC 

to compute the MS location 
for GPS Autonomous and 
h*pn.emeris Aiaing moae. 


Request Base Station 
Almanac 

(see Ref 4, section 3.2 4.1) 




CP to PDE 


Request for BS position 
information. 


Provide Base Station 
Almanac 

(see Ref 4, section 4.2.4.2) 




PDE to CP 


Provide BS position 
information for 
approximate MS position. 


Request Location Response 
(see Ref 4, section 4.2.4) 




PDE to CP 


Ask for location result and 
specify number of position 
fixes. 


Request GPS Ephemens 
(see Ref 4, section 3.2.4.1) 




CP to PDE 


Request PDE to provide 
Ephemens data. 


Provide GPS Ephemeris 
(sec Ref 4, section 4.2.4.2) 




PDE to CP 


Provide MS with Ephemeris 
data. 


Provide Location Response 
(see Ref 4. secUon 3.2.4.2) 




CP to PDE 


Provide MS location result 
to PDE. 
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8 IS-801 Messages £rom CP to PDE 

To provide the AI3 based location service, the CP shall set appropriate values to certain 
data fields in the IS-801 messages as described in this section. When the CP receives 
the position result from the SLC via the F interface, it shall convert the position result 
into IS-801 message format to be sent to PDE. 

8.1 Provide MS Information 

In response to the IS-801 "Request MS Information** message sent from PDE, the CP 
shall set the REQ_PAR.RECORD of the IS-801 "Provide MS Information" message as 
follows: 

1. GPS_ACQ_CAP and LOC_CALC_CAP of the RESP.PAR_RECORD shall be set to the 
values described below. 

GPS_ACQ_CAP (12 bits) - Bit 4 (GPS Ephemeris) and bit 7 (GPS Autonomous 
Acquisition Capable) shall set to '1', other bits shall set to '0^ The bit definitions are 
defined in Table 3.2.4.2-3 of Ref 4. 

2. LOC_CALC_CAP (12 bits) - Bit 5 (Location Calculation Capable using Ephemeris) and 
bit 7 (Autonomous Location Calculation Capable) shall set to *1', other bit shall set to 
'0', The bit defmitions are defined in Table 3.2.4.2-4 of Ref 4. 



8.2 Request Base Station Almanac 

If the CP chooses to obtain the approximate MS position via the IS-801 BS Almanac 
data, then the CP shall set the REQ.PAR_RECORD of the IS-801 "Request Base Station 
Almanac" message as follows: 

1. EXT_BS„ALM (1 bit) - set to 1. 

8.3 Request GPS Ephemeris 

The CP shall send the IS-801 "Request GPS Ephemeris" message to obtain the 
Ephemeris aiding data. The CP shall set the REQ_PAR_RECORD of the IS-801 "Request 
GPS Ephemeris" message as follows: 
1. AB^PAR^REQ (1 bit) - set to 1. 

8.4 Provide Location Response 

After receiving the "F' interface "Position Result" message from the SLC, the CP shall 
convert the position result data into the IS-801 "Provide Location Response" message as 
follows: 

1. TIME_REF_CDMA(14 bits) 

CP shall convert GPS time to CDMA system time. The GPS time is defined by the 
MEAS.GPS.WEEK and MEAS_GPS„SECONDS of the "F" interface "Position Result" 
message. The MEAS^GPS^WEEK is an extended GPS week number and the 
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MEAS^GPS.SECONDS is the number of elapsed time smce the begmning of the current 
GPS week, m an unit of 1 / 1000 seconds. The CDMA system time is defined in 1.2 of 
TIA/EIA-95-B. The TIME.REF^CDMA shall be set to (t/50) mod 16384 as defined m 
IS801, where t is CDMA system time m frames.2 LAT(25 bits) 

LAT » scale_factor„measJat x MEAS.LAT(Position Result message) 

LAT is in unit of 180/22S and MEAS_LAT is in the unit of 180/232 ^ therefore 

sc8|^f^factor.meas_lat = (180/232)/( 180/225) = 1/27; 
Note: the 32 bits computation result need to be converted to 25 bits by take the 7 MSBs 
out. 

3. LONG{26 bits) 

LONG = scale_factor_measJong x MEAS_LONG(Position Result message). 
LONG is in unit of 360/226 and MEAS.LONG is in the unit of 360/232 ^ therefore 

scale„factor.measJong= (360/232)/( 360/226) = i/26; 
Note: the 32 bits computation result need to be converted to 26 bits by take the 6 MSBs 
. out." 

4. LOC_UNCRTNTY.ANG(4 bits), LOC^UNCRTNTY.A(5 bits), LOC_UNCRTNTY J (5 bits) 
If the Bit 0 (LSB) of the OTHER_SECTIONS (Position Result message) is equal to *0'(No 
horizontal error section m the data), then 

LOC.UNCRTNTY.ANG =0 

LOC^UNCRTNTY^A ='11111' (Not computable) 

l6c_UNCRTNTY„P ='11111' (Not computable) 
Otherwise (the Bit 0 (LSB) of the OTHER_SECTIONS (Position Result) is equal to '1') 
The LOC_UNCRTNTY_ANG is in the unit of 5.625 degrees and with the range of from 0 
to 84.375 degree. The ER_EL_ANG(Position Result message) is in the unit of 0.75 
degrees and with a range from 0 to 179.25 degrees. Therefore 

scale_factor_ang = 0.75/5.625 = 0. 1333; 
If ER_EL_ANG < 120 ( 90 degree) then 

LOC_UNCRTNTY_ANG = scalejacter^ang x ER„EL_ANG 
If ER_EL_ANG >= 120 (90 degree) then 

LOC_UNCRTNTY„ANG « scale_facter_ang x (ER_EL_ANG - 120); , 
If ER^EL^ANG < 120 ( 90 degree) 

LOC_UNCRTNTYJV = MAJ^STD_ER(Position Result message) 

LOC_UNCRTNTY_P « MIN_STD_ER(Position Result message) 
If ER^EL^ANG >= 120 ( 90 degree) 
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LOC^UNCRTNTY.A = MIN_STD_ER(Position Result message) 

LOC_UNCRTNTY_P « MAJ__STD_BR(Posifaon Result message) 

The conversion from MIN^STD^R and MAJ^STD^R to LOC_UNCRTNTY_P and 
LOC_UNCRTNTY_A are based on Table 23 and Table 24 of Ref 2 and Table 3.2.4.2-10 of 
Ref 4. First the MIN_STD_ER and MAJ_STD_ER is converted to a number in an unit of 
meters by using Table 23 and Table 24 of Ref 2 and then mapping those nvimbers to a 
five-bit LOC^UNCRTNTY^P and LOC.UNCRTNTY_A using Table Table 3.2.4.2-10 of Ref 



5. FIXjrYPE(l bit) 

If POS_TYPE(Position Result message) = 0x00 then 

FiXjrVPE = 0 
If POS.TYPE = 0x01 then 

FDeTYPE = 1 

6. VELOCITY_INCL(l bit), VELOCITY«HOR(9 bits), VELOCITY_VER(8 bits), HEADING(IO 
bits) 

VELOCITY_INCL(IS801. 1 bit) = Bit 2 of OTHER_SECTIONS (Pojsition Result message); 
If VELOCITYJNCL = '1', 

VELOCITY^HOR = scale_factor_hv x HOR_VEL(Position Result message) 
scale_factor_hv = 0.0625/0.25 = 0.25; 

Note: the range of VELOCITY^HOR is from 0 to 127.75 m/s, while the range of 
HOR.VEL is from 0 to 4095 m/s. Thus when HOR_VEL >= 2044 (127.75 m/s), 
VELOCITY„HOR= 511 nillllllll. 

HEADING = scale_factor_heading x HEADING(Position Result message); 
scale Jactor.heading = (360/216)/ (360/2i0) = 2-6; 

Note: the range of HEADING(IS80 1) is from 0 to 360(1- 2-io) degrees, while the 
range of HEADING(F) is from 0 to 360(1- 2-i6). Thus when HEADIND(F) 
OxFFCO (359.648375 degrees) , HEADING(IS80 1) «'llllllllll'. 

If VELOCITYJNCL = '1' and FIXJTYPE = '1', 

VELOCITY_VER(IS801, 8 bits) = VER_VEL(Position Result message); 

If VELOCITYJNCL = '0* then the lS-801 "Provide Location Response" shall not include 
VELOCITY^HOR, VELOCITY^VER and HEADING parameters, 

7. CLOCKJNCL{l bit), CLOCK^BlAS(18 bits), CLOCK_DRIFT(16 bits) 
CLOCKJNCL = Bit 3 of OTHER^SECTIONS (Position Result message);. 
If CLOCK„INCL='l', 



4. 
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CLOCK_BIAS = scale_factor_clK„bias x CLK_BIAS(Position Result message) + 
ofrset_clk_bias; 

Where, 

scale_factor_clk_bias = le9; offset_clkL_bias = 13,000 ns 

Note: the range of CLOCK_BIAS is from -13,000 ns to 249,143 ns with a unit of 
1 ns, while the range of CLK^BIAS is from - 429.287 seconds to 429.287 
seconds with a minimum non-zero value of 100 ns and expressed in a "floating- 
point" format (defined in page 38 of Ref 2) with a unit of second. When 
CLK_B1AS < -13,000 ns, the CLOCK-BIAS is set to -13,000 ns. When CLKJBIAS 
> 249,143 ns, the CLOCK^BIAS is set to 249,143 ns. 



CLOCICDRIFT - scale_factor_clk_drift x CLK-DRIFT(Position Result message) ; 
where 

scale_factor_clk_bias = le3; ^ 

Note: the range of CLOCK_DRIFT is from -32768 ppb (ns/s) to 32768 ppb 
(ns/s) with aumt of 1 ppb (ns/s), while the range of CLKLDRIFT is from- 
327.52 ppm (us/s) to 327.52 ppm (us/s) with a minimum non-zero value of 
0.0025 ppm and expressed in a "floating-point" format (defmed in page 38 of Ref 
2) with.a unit of ppm (us/s). When CLK_DRIFT < -32768 ppb , the 
CLOCK^DRIFT is set to -32768 ppb. When CLK.DRIFT > 32768 ppb, the 
CLOCK-DRIFT is set to 32768 ppb. 

If CLOCKJNCL = '0' then the IS-801 "Provide Location Response" shall not include 

CLOCK_BIAS and CLOCK_DRIFT parameters. 



8. HEIGHT JNCL(1 bit), HEIGHT(14 bits) 

HEIGHT JNCL - Bit 1 of OTHER^SECTIONS (Position Result message); 
If HEIGHTJNCL='l', 

HEIGHT = scale_factor_height x HEIGHT(Position Result message) 

scale_factor_height = 0.1; 

Note: the range of HEIGHT(IS801) is from -500 m to 15833 m with the unit of 1 
m, while the range of HEIGHT(Position Result message) is from -500 m to 
6053.5m in units of 0. Im. Thus, the range .of values beyond 6053.5m will never 
be used in the HEIGHT(IS801) parameter. 

If HEIGHT JNCL = *0' then the IS-801 "Provide Location Response" shall not include 

HEIGHT parameter. 

9. L0C_UNCRTNTY_V(5 bits) 
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IfHEIGOTJNCL= '1', 

LOC_UNCRTNTY„V « HEIGHT_STD_ER(Position Result message); 

The conversions from HEIGHT_STD_ER to LOC„UNCRTNTY_V axe based on Table 25 of 
Ref 2 and Table 3.2.4.2-10 of Ref 4. First the HE1GHT_STD.ER is converted to a 
number m an unit of meters by using Table 25 of Ref 2 and then mapping those 
numbers to a five-bit LOC_UNCRTNTY„V usmg Table 3.2.4.2-10 of Ref 4. 



V 
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9 IS-801 M essages from PDE to CP 

The CP shall convert the received IS-801 messages as described in this section. 
9.1 Provide Base Station Almanac 

The CP shall receive the IS-801 "Provide Base Station Almanac" message from the PDE 
in response to the IS-801 "Request Base Station Abnanac''. This message provides an 
alternative to IS-95 impUcit method to obtain the approximate MS position data. 
The message mapping from the IS-801 ''Provide Base Station Almanac" to "F" interface 
"Approximate MS Position Response'* is described in this section. The field names of 
interface "Approximate MS Position Response" data are labeled with (F). The field names 
of the IS 801 "Provide Base Station Almanac" are labeled with (IS801) 

1. MESS_ID[F1 

MESS_ID (F) = the same value as in the latest «F" interface Approximate MS Position 
Request from SLC. 

2. LAT[F, 32 bits] 

LAT = scale Jactorjat x [LAT_REF(IS80 1 , 23 bit) + DELTA_LAT(IS801, 16 bits)]; 
Notes: 

a. LAT_REF is expressed as a two*s complemented signed number. Its sign bit has 
to be extended to the 9 MSBs of a 32 bits (signed long) before computation is 
taken. 

b. The unit for both LAT_REF and DELTA_LAT is 0. 125 arc seconds and unit for 
LAT is 180/232 degrees. Therefore 

scalejactorjat « (0.125/3600)/(180//232)., 

c. If the field LOC_SAME_AS_PREV(IS801) is equal to 1, the previous base station's 
DELTA^LAT value shall be taken for the computation. 

3. LONIF, 32 bits] 

LON = scale.factorjon x [LONG__REF(IS801. 24 bit) + DELTA-LONG(IS801, 16 bits)]; 
Notes: 

LONG^REF is expressed as a two's complemented signed number. Its sign bit 
has to be extended to the 9 MSBs of a 32 bits (signed lon^ before computation 
IS taken. 

The unit for both LONG_REF and DELTA.LONG is 0.125 arc seconds and unit 
for LON is 360/232 degrees. Therefore 
scalejactor = (0.125/3600)/(360//232); 



a. 
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) 

c. If the field LOC.SAME_AS„PREV(IS801) is equal to 1, the previous base station's 
DELTA^LONG value shall be taken for the computation 

4. ALT[F, 16 bits] 

ALT = scale_factor_h x HEIGHT(IS801, 10 bits) + h^oCTset. 
Notes: 

a. The HEIGHT is in the range from 0 to 4092 m (m the unit of 4 m) and is 
expressed in 10 bits. In the computation, it needs to be converted to 16 bits 
unsigned integer type. The 6 MSBs shall be filled with Os. 

b. The ALT is in unit of 0. 1 m and m the range from -500 m to 6053. 5m. Therefore 
Scale_factor„h = 4/0. 1 = 40; and h.offset = 500/0. 1 = 5000; 

c. If the field LOC_SAME_AS.PREV(1S80 1) is equal to 1, the previous base station's 
HEIGHT value shall be taken for the computation. 

5. EST_HOR_ERlF, 8 bits] 

The CP shall set this field using the estimated fiorizontal error (1 sigma) and encode it 
following Table 48 of Ref 2. 

9.2 Request Location Response 

This message shall provide the MS position request information as part of the AI3 
interface data. 

The AI3 message structure is defined in Ref 3 section 7.2.1. The message mappmgfrom 
the IS-801 •'Request Location Response" to AI3 data structure is described in this 
section. The field names of AI3 data are labeled with (AI3). The field names of IS 801 
Request Location Response are labeled with (IS801) 

1. NUM_FIXES(AI3) 

NUM_FIXES{AI3) = NUM_FIXES(IS801); 

2. TIME_,BTW_FIXES(AI3) 
If T_BETW__FIXES (IS801) < 128, then 

TIME_BTW_FIXES(AI3) = 2 x T^ETW.FIXES PSSO 1) ^ 

If T_BETW_FIXES (IS801) >= 128, then 

TIME_BTW_F1XES(AI3) = 255 

Note: both field are consist 8 bits. The scale factor of TIME_BTW^FIXES(AI3) is 0.5 
seconds. The scale factor of T^BETW^FIXES (13801) is 1 second. The range difference 
limited the ability of the SLC to handle the MS position request with 
T_BETW_FIXES(IS801) >= 128 seconds. 

3. HORI3RROI?^MAX[AI31 

HORI_ERROR«MAX(AI3) «= 0x07 { No maximum error hmit). 
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4. VERTjriME_MAX[AI31 



t 



VERT.ERROR^MAX(AI3) = Ox07{ No maximum error Umit). --^ 

5. RESP^TIME.MAXIAI3] 
RESP.TIME_MAX(AI3) = 111 (No time limit). 

6. TIME_ACC_PRIORITY[AI31 

TIME_ACC_PRIORITY (AI3) = 0x00 (No priority imposed ) 

Note: The IS 801 Request Location Response also includes clock correction for GPS time 
and velocity information, but current version of SiRFLoc does not provide those 
supports. Therefore those requests are ignored implicitly. 

9*3 Provide GPS Bphemeris 

This message shall provide the ephemeris data as part of the A13 interface data. 

The AI3 message structure is defined in Ref 3 section 7.2. 1. The mapping of IS-801 
''Provide GPS Ephemeris" to AI3 data structure is described bellow. The field names of 
AI3 data are labeled with (AI3). The field name of IS 801 Provide GPS Ephemens are 
labeled with (IS801) 

Depending on the size of the ephemeris data set, the PDE may send the IS-801 "Provide 
GPS Ephemeris" m several parts. The total number of parts and the part number of the 
message are indicated m the elements of TOTAL_PARTS and PART^NUM, respectively. 
When CP receives all parts of the ephemens data, it shall map them to AI3 structure as 
follows: 

1. AB^PARJNCL, ALPHA.O, ALPHA.l, ALPHA_2, ALPHA^3, BETA_0. BBTA^l, BETA^2, 
and BETA_3 of AI3 data 

The parameters AB^PARJNCL, ALPHA^O, ALPHA_1, ALPHA^2, ALPHA„3, BETA_0. 
BETA_1, BETA_2, and BETA__3 of AI3 data are defined identically in the IS-801 "Provide 
GPS Ephemeris". If the AB_PAR_INCL(1S8011 is equal to 1, the CP shall assign the A13 
parameters with the same values of the corresponding IS-801 data. Otherwise, the AI3 
data shall not be changed 

2. IONO_FLAG[A131 

lONO.FLAG (AI3) = AB_PAR^1NCL(IS801); 

Note: lONOP^FLAG is 8 bits and AB^PARJNCL is 1 bit. When AB„PAR,INCL is set to 1, 
lONO.FLAG = 1; When AB^PARJNCL is set to 0, IONO_FLAG = 0; 

The A13 structure has 32 slots for storing the ephemeris data for each sateUite. The slot 
sequence number shall match with the satellite PRN number (the maximum PRN 
number is 32). The ephemeris data of SV_PRN_NUM(AI3) shall be assigned to the 
ephemens data of SV_PRN^NUM(IS801) 

Most ephemeris parameters are defined identically in both AI3 and the IS-801 "Provide 
GPS Ephemens". They can be copied directly from IS 801 to AI3 with the foUowing 
exceptions 
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EPH_FLAG(Ai3) = 1; valid ephemens 

SV„PRN_NUM(AI3, 8bits) = SV_PRN_NUM(IS801, Sbits) + l;fill Os in the 2MSBs 

URA_IND(AI3) 15; no accuracy prediction is available. 1S801 does not contain this 
information; 

OMEGADOT(AI3, 32 bits) = OMEGADOT (1S801, 24 bits); extend 24^^ bit to the 8 MSB 
of AI3 data; 

IDOT(AI3, 16 bits) = IDOT(IS801, 14 bits); extend 14* bit to the 2 MSB of AI3 data; 
AF0(AI3, 32 bits) = AFO( IS801» 22 bits); extend 22n«« bit to the 10 MSB of AI3 data; 

10 Theory of Operation 

The CP shall interact with the SLC via the "F" interface messages. The CP shall send 
the AI3 data to SLC whenever the new A13 data is available (without the request from 
SLC). There is no interaction between the CP and the SLC via the AI3 interface. 

The lS-801 session of the CP may be opened before the SLC is powered on or before the 
SLC session (set with the A13 interface flag) is opened. The SLC session shall be closed 
before the closing of the IS-801 session. When the IS-801 session is opened, the CP 
shall reset the AI3 data structure. 

If the IS-801 session is opened before the SLC is powered on, the CDMA system time 
will be available before the CP is ready to perform the time transfer with the SLC. In 
this scenario, the CP may also get the approximate MS position data before the SLC is 
ready to send the "F" interface "Approximate MS Position Request* and hence the GPS 
performance of the SLC will be more optimized. 

The CP can obtain the approximate MS position via either the IS-95 implicit method 
(from IS-95 "System Parameter Message") or the IS-801 messages (as described in 
7.1.1). The IS-95 implicit method is considered to be the faster way of getting the BS 
position compared to the IS-801 messages. The IS-95 "System Parameter^ is a required 
message to be sent to the CP from the BS during the CDMA MS Idle State, regardless of 
the IS-801 session. On the other hand, the IS-801 "Request/ Provide Base Station 
Almanac" not only requires two interactive message exchange, but also will not invoked 
until the IS-801 session is opened. 

When the CP converted a complete new set of ephemens data from BS via the IS-801 

interface, the AI3 data is considered to be ready. The CP shall send the A13 data to SLC 

less than 2 seconds after the AI3 data is ready, without the asking from the SLC. The 

CP should periodically request the BS to send the ephemens data at a rate no longer 

than 2 hours. The faster the rate, the more opUmized the GPS performance, 
f 

The SLC shall penodically send the position result to the CP via the "F" interface based 
on the number of posiUon fixes as specified in the AI3 data structure. The CP shall set 
the number of position fixes m the AI3 structure even if the data is not available. 
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An example of AI3 message flows is presented m Figure 3. 
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Figure 3 - AI3 Message Plow for IS-801 Handset 
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1 Scope 

This document is to guide the designer of the Call Processing (CP) software for the 
implementation of the translation software to convert the RRLP protocol messages to 
SiRFLoc Aiding Independent Interoperabihty Interface (AI3) structure for a SiRFLoc 
based Mobile Station (MS). 

The recommendation to be presented m this document can be implemented even by a 
non-GPS specialist. 

This document only presents a recommended implementation for the customers to 
implement the AI3 architecture inside the CP software, but by no means represents the 
only implementation approach. 

2 System Overview 

The mobile station consists of a CP and a SiRFLoc Client (SLC). The CP refers to the 
dedicated hardware and software to establish and manage wireless communication with 
the base station. The SLC refers to the GPS section to receive GPS signals and 
determine the mobile station geographic location. It is composed of the "Aiding- 
Independent-Interoperabihty-Interface" layer, to dialog with the CP, on top of the SiRF 
GPS core technology. 

Whereas SiRFLoc encompasses several architectures; the only one for which AI3 
interface shall be used is the "Aiding Independent Interoperabihty Interface 
Architecture". The CP implements the Geolocation air-interface protocol (from 
Geolocation Server to CP) and then passes GPS aid information received from the base 
station to the SLC, over the AI3 as shown m Figure 1. 
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Figure 1 - Wireless Mobile Position System Architecture- AI3 Architecture 

Table 1 describes the interfaces shown in Figure 1, There are diiferent geolocaUon 
standards developed for different types of wireless networks; anyone can be the "H" 
interface. 



Table 1 Interface Descnption 



Interface 


Functional 
Entities 


Protocol 


Description 


H 


Geolocation 
Server-CP 


Air-interface 


Various geolocation standards. 
Controlled by the CP manufacturer. 


F 


CP-SLC 


SiRFLoc 
Specifiq 


SiRFLoc Client Interface Control 
Document 


G 


CP-SLC 


SiRFLoc 
Specific 


SiRFLoc AI3 Interface Control Document 



The F interface, which is the client system interface between SLC and CP, is defined in 
SiRFLoc Client Interface Control DocumenL It acts as a bootstrap protocol, ever present, 
allowing the CP to choose at run-time between an air-interface (case of the end-to-end 
system architecture) and the AI3. It is designed to perform the following tasks: 

• SLC hardware management from the CP (power on/off, reset); 

• If available, implicit aiding interface, i.e. time and frequency transfer from 
network (or from CP real time clock) via the CP, and approximate position (from 
the network, if it does exists), 

• Session opening/ closing (i.e. notifying the SLC that an air-interface connection 
has been opened/ closed); 

• In a dual-mode MS, notifying the SLC what air mterface is on, and thus 
notifying the SLC what set of geolocation air-interface protocol to use to dialog 
with the SLS; 

• Interfaces locally with the CP to allow the user to locally trigger a geolocation, 
and to report the position for display or usage at the MS; 

• Convey the position results to the CP for MS local usage only. 

In the "Aidmg Independent Interoperability Interface Architecture", it is the CP 
developer's responsibility to implement the Geolocation protocol that is used between 
the Geolocation Server and CP. The G interface'is used to convey position request and 
GPS aiding information received from the base station to the SLC. It is also used to 
report position results from SLC to PC. 

Since there are many existing Geolocation protocols, the G interface is designed to be 
usable over a large range of Geolocation standards and air-mterface independent, i.e. it 
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is unique for appbcable air-interfaces. The "AI3" is actually a reduction of the applicable 
Geolocation standards. It will not be optimized for any of them. 

The position results from SLC are conveyed to CP through both G interface and F 
interface for AI3 logical consistency and SLC chent ICD consistency. The position 
results from AI3 interface shall be translated to RRLF position mformanon and be 
passed to SMLC. 

AI3 IS an interface, not a protocol. There is a fundamental difference between an 
interface and a protocol. The protocol is an interactive process, where the information is 
explicitly requested and explicitly answered. Only the information really needed is 
requested. The mechanism of error detection and request for repetition is quite 
sophisticated. On the other hand, the interface does not imply any mteraction between 
the 'two interfaced entities. All information has to be part of the message. There is no 
need for a sophisticated error correction scheme, and the size of the message can be 
quite large. ^ 

The AI3 shall be used exclusively between CP and SLC over a serial connection in the 
mobile station. It shall not be used over the air as the volume of exchanged information 
is quite significant. 

3 Revision History 



Revision 


Date 


Description 


Editor 


Revision 1.0 


August 1.2001 


Initial official version 


Q. John 

Zhang/ Steve Chang 



4 Glossary 

2D Position. A two-dimensional (latitude and longitude) position. 

3D Position, A three-dimensional (latitude, longitude, and height) position. 

Aiding Independent Interoperability Interface (AI3). Generic aiding interface 
between CP and SLC, mdependent from the actual Geolocation protocol between 
Geolocation Server and CP. 

Aiding Data. The data provided by the base station to the mobile station for various 
purposes (e.g., acquisition, location calculation or sensitivity improvement). 

Generic Geolocation Server Station. This term refers to the entity m the network 
which provides aid (GPS-related or other) information to the SLC, and retrieves the 
position results. It has different names depending on the cellular platform of interest 
(SMLC for RRLP, GMLC for GSM,...) 

Call Processor (CP). The dedicated hardware and software to establish and manage a 
wireless radio connection. 
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Bphemeris. The ephemeris data are embedded in the GPS Navigation Message. The 
precise (high accuraQr) orbital parameters of one GPS satellite, as transmitted by that 
satellite in the GPS NavigaUon Message Subframe 1, 2, and 3. The ephemeris also 
mcludes satellite clock correction. 

Qeolocation. The process of determining a geographic location. 
GPS. Global Positionmg ^stem. 
ICD. Interface Control Document. 

Mobile Station (MS). It consists of a CP and a SLC» communicates with the base 
station and receives GPS signals. 

SiRFLoc Client (SLC). The SiRFLoc GPS section embedded m the mobile station. It is 
composed of a protocol layer, to dialog with the CP and SLS through the CP, on top of 
the SiRF GPS co.re technology (hardware and software). 

SV. Space Vehicle or Satellite.* 

LCS: Location Service 

SMLC: Serving Mobile Location Center 

RRLP: Radio Resource LCS Protocol. 

BTS: Base Transceiver Station 

BSC: Base Station Controller 

MSB: Most Significant Bit 

LSB: Least Significant Bit 

5 References 

Ref 1 - ICD-GPS-200C. Navstar GPS Space Segment/ Navigation User Interfaces. 
September 1997 

Ref 2 - SiRFLoc Client Interface Control Document, Rev 1.4, May 4, 2001 

Ref 3 - Aiding Independent Interoperability Interface Control Document, Rev 1.2, Aug, 



Ref 4 - 3GPP TS 04.31 version 8.5.0 Release 1999 - ETSI TS 10 1 527 V8.5.0 (2001-6), 
Radio Resource LCS Protocol 

Ref 5- GSM 01.04 version 7.0.0 release 1998. ETSI TR 101 748 V 7.0.0(1999-08), 
Abbreviations and Acronyms 

Ref 6- GSM 03.32 version 7.1.0 Release 1998, ETSI TS 101 109 v7.1.0 (2001-10) 
Ref 7 - 3GPPTS09.31, version 7.5.0 (2001-5), Release 1998 



2001 



Information Proprietary to SiRF Technology* Inc. 



-8- 



SIRFLoc: RRLP Protocol to SiRFLoc AI3 Implementation Guidelines Rev l.Odraftl.l 



6 Handset Design Concept with AI3 for GSM/3GPP 

The purpose of the AI3 concept is to make the SLC based handset to work with any 
geolocation air-interface protocol for network aided data with or without SiRFLoc 
Server. The current AI3 architecture supports the network aidmg with Ephemeris data 
or Almanac data. 

Figure 2 shows the high level architecture of AI3 to be implemented mside the RRLP 
based handset. The CP shall communicate with the SLC via a RS232 link and 
hardware lines (for the time and frequency transfers) as described in Ref 2. The F and 
G are two separate logical channels for the RS232 interface. The O interface is designed 
to pass the AI3 aiding data to SLC. The rest of the aiding data will be passed to SLC via 
the F interface. On the SLC side, the F interface is a standard SiRFLoc client interface 
and the G interface is transparent to any standard air-interface protocols. The CP shall 
generate the AI3 data via an "RRLP message to AIS" converter. The AI3 data will be 
packed into the G message format via an A13 interface message handler before passing 
to SLC via the RS232 link. The CP may obtam the time, and reference location data 
from an appropriate RRLP air-mterface messages and pass them to SLC via appropriate 
"F" interface messages. \ 




F/G 




Figure 2 - General concept of A13 architecture for RRLP based handset. 

7 RRRLP Aiding Data and Responses versus the CP/SLC Interface Logical 
Channels 

7.1 RRLP Aiding data receiving and transmitting 

The RRLP messages can provide the aidmg data required by the SLC for A-GPS position 
computation. The CP will pass the RRLP aiding data to SLC via the AI3 or F interfaces. 
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Table 2 



Table 2- RRLP Aiding data and the corresponding aiding interface messages 



RRLP Data Type 


CP and oLC 
Logical 
Channel 


Interface Message 


Positioning Information 
- Response Time, 
Accuracy 


GIAI3] 


AI3 Request Message - PosiUon Request QoS 
parameters 


Reference Time - GPS 
time, GPS time of the 
week 


F(SLC sysem) 


Time Transfer Response Message. 


UTC Model 


F(SLC system) 


Time Transfer Response Message. 


Reference Location 


F(SLC system) 


Approximate MS Position Response 
Message. 


Navigation Model - 
Ephemeris data 


G(AI3) 


AI3 Request Message - Eph data 


lONO Model 


G(AI3) 


AI3 Request Message - lONO parameters 


Almanac data 


G(AI3) 


AI3 Request Message - Almanac data 



Table 2 lists the possible aiding data that may be provided by RRLP messages, but some 
of these data and other aiding data may also be obtained from the GSM or 3GPP Base 
Station via the standard GSM or 3GPP mobile telecommunication data messages. The 
method of obtaining the aiding data via the mobile data messages is beyond of the 
scope of this document. 

7*2 AI3 response data and RRLP Response Messages 

Table 3 lists the AI3 response data that will be provided by the SLC for RRLP response 
messages. 

J 

Table 3 - AI3 data to support RRLP Response Messages 
7.3 Sample Messages Flows 

Figure 3 shows the general idea of the A-GPS RRLP message flows for MS using AI3 
based SiRFLoc Client. 
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Figure 3 - Demonstration of RRLP to AI3 message flows 

The purpose of this message flows is to demonstrate an example of the information 
transfer and it should not be interpreted as a procedure to be followed for 
implementation. In particular, the sequence of the messages flow for a location service 
can be different from the one illustrated. 

1.) The CP may receive a location service request from the network via the RRLP 
Measure Position Request message before it starts the SLC. 
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2. ) The CP will decode the Measure Position Request message and generate an AI3 data 

buffer for AI3 aiding. The CP may use the Reference Locabon data from the 
Measure Position Request message as the approximate position data for the F 
mterface Approximate MS Position' Response message. The CP may also use the 
Reference Time mformation from the Measure Position Request message as the time 
data for the F interface Time Transfer Response message. The CP will convert other 
aiding data such as the position request QoS parameters* the lONO parameters and 
the Ephemeris data into the internal AI3 data buffer. Noface that in this message 
flows, we assume that the Measure Position Request message does not contain the 
Almanac data. 

3. ) After recognizes the position request, the CP may start the SLC by powering on the 

GPS unit. 

4. ) The SLC shall first send the F interface Hardware Configuration Request message 

after the CP turns on the power of the GPS umt. 

5. ) The SLC will send an Approximate Position Request message after receiving the F 

interface Hardware Configuration Response message. 

6. ) The CP may choose to send the F mterface Approximate Position Response message 

using the position data provided by the RRLP Measure Position Request message. 

7. ) The SLC may also sends the F interface Time Transfer Request message after 

receives the Approximate Position Response message from the CP, 

8. ) The CP may choose to send the F interface Time Transfer Response message using 

the time data provided by the RRLP Message Position Request message. 

9. ) The SLC may send the F interface Frequency Transfer Request message after 

receives the Hardware Configuration Response message from the CP. 

10. ) After sends the F interface Frequency Transfer Request message, the CP may 

send the F interface Session Opening Request message to SLC. 

1 1. ) The CP may send the G interface AI3 Request message after receives the F 
interface Session Opening Response message. 

12. ) The SLC always send the ACK or NACK message in response to the AIS Request 
message. 

13. ) After computes the position result, the SLC will send the AI3 Response message 

to the CP. As part of the AI3 Response message, the SLC always provides the 
Almanac agi ng data. 

14. ) After receives the position result from the AI3 Response message, the CP may 
send the RRLP Measure Position Response message to the SMLC and request the 
Location Server to provide the Almanac data (if the CP decides the Almanac data m 
the SLC needs to be updated based on the Almanac aging data as provided by the 
SLC in the AI3 Response message). 

15. ) The CP will receive the Almanac data from the Location Server in the RRLP 
Assistance Data message. 
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16. ) The CP will send the Almanac data to SLC for Almanac update mside the GPS 
unit via an AI3 Request message (contains only the Almanac data). 

17. ) The SLC will send the ACK after successfully receives the Almanac data. 

18. ) The CP may choose to close the location service by sending the F interface 
Session Closmg Request message to SLC. 

19. ) The SLC will send the P interface Session Closmg Response message to CP after 
finishes the house keepmg for session close. 

20. ) The CP may choose to turn off the power of the GPS unit after receives the F 
interface Session Closing Response message. 

8 RRLP Aiding Data Conversion to AI3 and P interlace messages 

There are two RRLP components from SMLC to MS are needed for MS based GPS 
positioning. They are "positionlnstruct" and "gps-AssistData". The "positionlnstruct" is 
a mandatory field of "measure position request". The "gps-AssistData" is an optional 
field for both "measure position request" and "Assistant Data". 

8.1 Position Instructions 

For supporting AI3 operation, the RRLP "position instructions" must has its "method 
type" set to value of 1, 2; or 3 (MS based, MS based is preferred or MS based is aUowed) 
and its "positioning method" set the value of 1 or 2 ("GPS" , or "B-OTD or GPS"), The 
"Positionlnstruct" provides some of the parameters of AI3 "position request". The rest of 
them need to be filled with defaulted values. 

1. NUM^FIXS (A13) 

RRLP does not have this information field and is not able to request multiple MS 
position. The value of NUM^FIXS shall set to 1. 

2. TIME_BTW„FIXES(AI3) 

This field indicates the time between two consecufave position fixes. Since RRLP can 
only request one MS position fix, this value shall set to 0. 

3. HORI_ERROR_MAX (AI3) 

This field provides the maximum requested horizontal error with a 95% of the cases 
having an error less than this value. The 7-bit "accuracy" field of the RRLP 
"positioning instructions" provides requested one sigma value of the horizontal error 
for the position. Table 1 of Ref. [6] (GSM 03.32 ) and Table 6 of Ref. [3] (AI3 ICD) 
provide the error codes for the two protocols, respectively. In two-dimension cases, 
the probability of the position within one sigma ellipse is 39%. To increase the 
probability to 95%, the error range need to be increased by 2.45 times. That is 

HORI „ ERROR _ MAX{AI3) = 2.45 x accuracy(RRLP) 
Table 4 gives the error code matches between the two protocols 
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Table 4. AI3/ RRLP Position Error Conversion 



AI3 HORI SRROR MAX value 


RRLP 7 -bit Uncertaintv code 


0x00 


0x00 


0x01 


0x01 and 0x02 


0x02 


0x03 


0x03 


0x04 to 0x07 


0x04 


0x08 to OxOA 


0x05 


OxB to OxOF 


0x06 


0x10 to 0x15 


0x07 


0x16 to 0x7F 


0x08-0xFF (Reserved) 


0x80 to OxFF (invalid) 



4. VERT^ERROR^MAX (AI3) 

Since the RRLP positioning instructions do not provide vertical positioning error 
request, the AI3 VERT_ERROR_MAX shall be Mled with the value of 0x07 indicating 
no maximum error limit. 

5. RESP_TIME_MAX(AI3) 

The AI3's RESP„TIME_MAX and RRLP positioning instructions' "response time" are 
defined in the same way. The "response time" value shall be set to the same value of 
RESP^TIME^MAX. 

6. TIM_ACC^PRIORITY (AI3) 

This parameter provides an instruction for SLC to choose priority when response 
time and location accuracy requests are contradicting But RRLP MsrPosition -Req 
does not provide this kind of dictation. SLC is required to make its own decision 
to meet both time and accuracy requirements. This value shall be set to 0x00. 

8.2 GPS-AssistData 

The "GPS assistant data", which can be a component of RRLP or a field of the 
positionlnstruct component of RRLP, provides ionospheric model, navigation model and 
almanac to SLC through G (AI3) interface. It also provides reference location and 
reference time to SLC through F (SLC system) interface. 

1. lONO^FLAG (AI3) 

When ionospheric model is available in the RRLP GPS assistant data, the 
lONO.FLAG shall be set to 1, otherwise it shall be set to 0; 

2. ALPHA.O to Beta^3 (A13) 
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The A13 parameters of ALPHA_0 to Beta^3 and RRLP ionospheric model Oq and 
Po have exactly the same definitions. The values of oto and Po shaU be directly 
assigned to ALPHA-0 to Beta_3. 

3. EPH_FLAG(AI3) 

The AI3 structure has 32 slots for storing the ephemens data , one for each 
satellite. The PRN number (1 to 32) of the satellite shall match with the slot 
sequence number (1 to 32). When a valid ephemeris of a satellite is available the 
EPH^FLAG shall be set to 1; otherwise the EPH^FLAG and the whole slot are set . 
to 0; To be considered as a valid ephemeris data, all the 6 bits of the "SV health" 
m the ng^vigation model (RRLP) must be 0; otherwise the ephemens data shall be 
considered as an invalid ephemeris. 

4. Ephemens Parameters for Each Satellite {AI3) 

Most ephemeris parameters are defined identically m both AI3 and the RRLP 
"navigation moder. They can be copied directly from RRLP to AI3 with the 
following exceptions. 

SV„PRN^NUM(AI3, 8bits) = SatlD(RRLP, 6bits) + 1; fill Os in the 2 MSBs. 
URAJND(AI3, 8 bits) = URA index (RRLP, 4 bits); fill Os in the 4 MSBs. 
IODE(AI3, 8 bits) = 8 LSBs of the 10 bit lODC (RRLP, 10 bits) 
OMEGADOT(AI3, 32 bits) « OMEGAdot (RRLP, 24 bits); extend 24th bit to the 8 
MSBs of OMEGADOT; 

IDOT(AI3, 16 bits) - Idot(RRLP, 14 bits); extend 14»i» bit to the 2 MSBs of lODT; 
AF0(AI3, 32 bits) « a&( RRLP, 22 bits); extend 22nd bit to the 10 MSBs of AFO; 

5. ALM„DATA_FLAG (AI3) 

This field indicates whether the almanac information is available in the AI3 
structure or not. When it is available, this field shall be set to 1, otherwise it is 
set to 0. 

6. ALM^WEEKLNUM (AI3) 

This field shsdl be set to the same value of WNa (RRLP) 

7. ALM_VAUD_FLAG (A13) 

The AI3 structure has 32 slots for storing the almanac data, one for each 
satellite. The satellite PRN number (1 to 32) shall match with the slot sequence 
number (1 to 32). When a valid almanac of a satellite is available the 
ALM_VALID„FLAG is set to 1; otherwise the ALM_VAL1D_FLAG and the whole 
slot are set to 0; To be considered as a valid ephemeris data, all the 8 bits of the 
«SV health" in the almanac (RRLP) must be 0, otherwise the almanac data shall 
be considered as an invalid almanac 

8. Almanac Parameters for Each Satellite (A13) 
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Most almanac parameters are defmed identically in both AI3 and the RRLP. They 
can be copied directly from RRLP to AI3 with the followmg exceptions. 

ALM_SV_PRN_mJM(AI3, Sbits) = SatID(RRLP, 6bits) + 1; fill Os in the 2 MSBs. 

ALM_AFO (16 bits) = afc (RRLP, 1 Ibits), extend 1 1* bit to the 5 MSBs of ALM^AFO. 

ALM_AF1 (16 bits) = afj (RRLP, llbits), extend 11^ bit to the 5 MSBs of ALM^AFl. 

9. Approximate MS Position Response (F Interface) 

The "Reference Location" field of the "GPS Assistance Data** element of RRLP 
provides mformation required by "Approximate MS Position Response" (F Interface 
message). 

LAT (F) is a 4-byte two's complement binary number. It ranges from -90 degrees to 
90(1- 2*^*) degrees. The latitude defined in RRLP is a 3- byte parameter ranging from 
-90 degree to 90(1- 2*") degrees with its first bit as sign bit and the rest of 23 
represent the absolute value of the latitude. The equation (1) shall be used for 
conversion. 

LAT = signxiN + 0,5)x2^ ( l) 

Where N is the coded number of £he 23 bits latitude (RRLP), the sign is equal to 1 
when the sign bit (RRLP) is 0 (North) and it is equal to -1 when the sign bit(RRLP) is 
1 (south). Since the LAT(F) has a higher resolution than the "latitude''(RRLP) and the 
actual absolute value of latitude is between N and N+1, the value of 0.5 is added to 
achieve statistic balance. 

LON (F) IS a 4-byte two's complement binary. It ranges from -180 degrees to 180(1- 
2"^') degrees. The longitude is coded in two's complement binary on 24 bits. It covers 
the same range. The equation (2) shall be used for the conversion. 

LON = (iV + signiN)0.5) x 2« (2) 

Where the N is the number of the 24 bits longitude (RRLP), sing(N) is equal to 1 
when N is a positive number and it is equal t -1 when the N is a negative number. 
Since the LON(F) has a higher resolution than the "longitude''(RRLP) and the actual 
value of longitude is between N and N+1, the value of 0.5 is added to achieve 
statistic balance. 

i 

ALT(F) is a 2-byte number in unsigned binary offset coding, ranging from -500 
meters to 6053.5 meters m unit of 0.1 meters. The altitude of RRLP is a tew bytes 
parameter. The MSB in the most significant byte presents the direction, 0 for height, 
1 for depth. The 15 LSBs are absolute value of the altitude encoded in increments of 
1 meter. When the altitude is from -500 meters (500 meters in depth) to 6053.5 
meters (6053.5 meters in height), the conversion shall be 

ALT^signxN*lO-h 5000 ( 3) 
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The value of "sign" is 1 when the direction bit (RRLP) is 0 (height) and it is -1 when 
the direction bit is 1 (depth). The N is the binary number of the 15 LSBs. 

When the altitude is deeper than 500 meters in depth, ALT = 0x00; When the 
altitude is higher than 6053.5 meters the ALT = OxFFFF; 

EST_HOR_ER (F) is the estimated honzonLal error for the approximate MS position. 
Smce the RRLP reference location does not provide its uncertainty, this 1 byte 
parameter shall set to OxFF. If the RRLP GPS assistance data provider uses the 
serving BTS position as the approximate MS position, the Timing Advance 
parameter can be used to estimate the maximum distance between the serving BTS 
and the MS, which can be used for the EST^HOR^ER. 

10. Time Transfer Response (F) 

RRLP reference time fields specify the relationship between GPS time and air- 
interface time of the BTS transmission in the reference cell. Together with the 
Timing Advance (signal propagation round-tnp delay between the MS and BS), it 
provides MS the ability to compute GPS time and synchronize MS clock to GPS time 
frame. See Ref [2] for detailed method and algorithm for time transfer from' CP to 
SLC. Note, the GPS.WEEK^NUM(F) is the absolute week number and the "GPS 
Week" of reference time (EU^P) has short week number format with modulo of 
1024. Currently, before next rollover (in the year of 2019), 

GPS_WEEK„NUM(F) = GPS Week (RRLP) + 1024; 

The time transfer response (F^ message also includes DELTA_UTC, this information 
can be obtained from UTC model (EWLP). See Ref. [l], section 20,3.3.5.2.4 for 
computing DELTA_UTC. 

Note: For iDEN and 3G wireless networks, precise GPS time is available at the CP 
and the "reference time" (RRLP) message may not be needed for time transfer. 

1 1. Frequency Transfer Response (F^ 

RRLP GPS assistance data does not provides reference frequency information. MS 
synchronize its frequency with BTS through frequency correction burst. See Ref [2] 
for details on frequency transfer from CP to SLC. 

9 RRIrP Messages from MS to SMLC 

In response to SMLC's "measure position request", the MS send "measure position 
response" message to SMLC. and send it to SMLC. This "measure position response" 
shall include "Locationlnfo" element in the case of MS based GPS location method. 

9.1 Location Information Element (RRLP) 

When the CP receives the "position result" from the SLC and its "position status" field is 
0x01 (position information available), it shall convert the "position result" (AI3) into 
"locationlnfo" (RRLP). 

1. GPS TOW (RRLP) 
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The 24 bits of GPS TOW of locafaon informahon (RRLP) are the LSBs of GPS time of 
week. Both the "GPS TOW** (RRLP) and the "MEAS^GPS^SECONDS" (32 bits, F) are 
m the unit of milliseconds. The "GPS TOW"(RRLP) shall be equal to the 24 LSBs of 
the •'MEAS_GPS„SECONDS''(AI3). The MSBs shall be derived by the SMLC to 
unambiguously derive the GPS TOW. 

2. FixType(RRLP) 
FixType(RRLP) = POS_TYPE(AI3) 

3. Position Estimate (RRLP) 

The position estimate allows several shapes. Which shape shall be used is 
dependent the data availability indicated in "OTHER SECTIONS" field of "Position 
Results"(AI3). Table 5 shows their relationship. 



Table 5. Shapes of Location Estimates 



Values of OTHER_SECTIONS (AI3) 


Shapes of Location Estimate (RRLP) 


QxOO 


Ellipsoid Point 


QxOl 


Ellipsoid Pomt with Uncertainty Ellipse 


0x02 


Ellipsoid Point with Altitude 


0x03 


Ellipsoid Point with Altitude and Uncertainty 

Ellipsoid 



The parameter conversions from "Position Results" to "Location Estimate** are hsted 
here. 



• The latitude defined in RRLP(Ref. [6]) is a 3-byte parameter ranging from -90 
degree to 90(1- 2"^^) degrees with its first bit as sign bit and the rest of 23 
represent the absolute value of the latitude. The MEAS.LAT is a 32 bits Two's 
complement value of the latitude ranging from -90 degrees to 90(1- 2"^*) degrees. 
The value of the 23 LMBs of the latitude (RRLP) shall equal to the absolute value 
of MEAS_LAT (AI3) divided by 2^. The MSB of the most significant byte of 
latitude (RRLP) shall equal to the MSB of the most significant byte of the 
MEAS_LAT (AI3). 

• The longitude defined in Ref. [6J is coded in two's complement binary on 24 bits. 
It covers the range from -180 degrees to +180 degrees. MEAS_LONG (AI3) is a 4- 
byte two's complement bmary. It ranges from -180 degrees to 180(1- 2*^') 
degrees. The conversion should be 

24-bit longitude of RRLP = 24 bits MSBs of the 32-bit MEAS^LONG 

• The values of AI3's MAJ^STD^ER and MIN_STD_ER shall be derived from Table 
13 and 14 of the Ref. [3] and converted to the 7-bit "uncertainty semi-major" and 
7- bit "uncertainty semi-minor^ of RRLP according to section 6.2 of the Ref. [6] 
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• Orientation of the major axis (RRLP) is a 8-bit binary number in a unit of 2 
degrees in the range of 1 to 179 representing angle ranging from 0 to 360 
degrees. The ER_EL_ANG(AI3) is a 8-bit binary number in the unit of 180/2*. 

Orientation (RRLP) = ER_EL_ANG(AI3) xl80/2'. 

• For the shape of Ellipsoid Point with Uncertain^ Elhpse, the parameter of 
"confidence" shall be filled by number of 39. For the shape of Ellipsoid Point 
with Altitude and Uncertamty Ellipsoid, the parameter of coniidence shall be 
filled by number of 20. 

• The "altitude" '(RRLP) is encoded in increments of 1 meter using 15 bit binary 
coded number N. There is a direction bit, 0 for height, 1 for depth. The 
HEIGHT(AI3) is a 2-byte number in unsigned binary offset codmg, ranging from 
-500 meters to 6053.5 meters in unit of 0.1 meters. The conversion shall be 

N ^{(HEIGHT- 5000)/ 10\ ( 4) 

When the HEIGHT is less than 5000. the direction bit of the altitude shall be set 
to 1 (depth), otherwise it shall be set to 0 (height). 

• The "Uncertainty Altitude" (RRLP) is the uncertainty in altitude coded in 7-bit 
binary number. The coding method is described in section 6.4 of Ref. [6]. The 
HEIGHT_STD_ER {AI3) is coded in an 8-bit binary number. The coding method 
IS defined in Table 15 of Ref. [3]. First, the 8-bit HEIGHT.STD^ER shall be 
converted to a value in meters and then it shall be coded to the 7- bit 
Uncertainty Altitude. 

9.2 Location Error Information Element (RRLP) 

When the CP receives the "position results" from the SLC and its "position status" field 
IS 0x00 (position error information), a position error is reported The position error field 
shall be mapped to Location error mformation element of RRLP. When the reason of the 
position error is "need more time", the CP shall wait for the position results for a 
predetermined time, usually the "response time" of the position instruction. At the end 
of that time if CP does still not receive the position results, it shall send a location error 
information element to SMLC with a location error reason of "undefmed error). 



Table 6 Location Error Reasons 



Error Descriptions 


Position error (AI3) 


Error Reason (RRLP) 


Not enough GPS satellites 


0x00 


1 


GPS assistance data missing 


0x0 1 


6 


Need more time 


0x03 


0 (undefined error) 


Time out 


0x04 


8. 
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10 Theory of Operation 

The CP may start the SLC at any time in the following possible choices: 



The CP shall interact with the SLC via the "F" interface messages for system 
configuration information exchange, geo-location session management, and time and 
frequency transfer. The approximate MS posibon information is also passed to SLC 
through F interface . 

The RRLP session of the CP may be opened before the SLC is powered on or before the 

SLC session is opened. The SLC session shall be closed before the closing of the RRLP 
session. When the RRLP session is opened, the CP shall reset the A13 data structure. 

If the RRLP session is opened before the SLC is powered on and all the information, 
such as time, frequencgr and approximate MS position, are available before SLC 
requesting for them, the GPS performance of the SLC will be more optimized. 

When the CP converted a complete new set of GPS assistance data or Measure position 
request from SMLC via the RRLP interface, the AI3 data is considered to be ready. The 
CP shall send the AI3 data to SLC less than 2 seconds after the AI3 data is ready, 
without the asking from the SLC. The SLC shall periodically send the position result to 
the CP via the "AI3" interface based on the number of position fixes as specified in the 
AI3 data structure. The CP shall set the number of position fixes in the AI3 structure 
according to the contents of measure position recjuest message from SMLC. 

1 1 Message Flows 

An example of AI3 message flows is presented in Figure 4. 
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Figure 4 - AI3 Message Flow for RRLP Handset 

StRFLoc AQ Poadon Computation Bflossaeo Flows for RALP GSM Handset (eumplft) 



m&ao 




Information Proprietary to SIRF Technology, Inc. 



-21- 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 



BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




